团队作业3--需求改进&系统设计

课程 2024软件工程
作业要求 团队作业3--需求改进&系统设计
作业目标 改进需求规格说明书

高校宿舍管理系统:从需求剖析到项目推进

一、需求 & 原型改进

(一)问题与修改

问题 1:原宿舍管理系统功能局限于管理事务,忽视学生社交需求。

修改 1:在深入调研学生校园生活后发现,学生们不仅需要一个管理宿舍事务的平台,更渴望有一个专属的社交空间来拓展人际关系、交流兴趣爱好和分享校园生活。因此,我们决定在原系统基础上新增社交圈功能,包括建主题圈、发布话题、话题审核、话题评论以及聊天功能等,以满足学生多样化的社交需求,打造一个集宿舍管理与社交互动于一体的综合性平台。

问题 2:原系统用户参与度低,缺乏用户自主创造和互动机制。

修改 2:通过对学生行为和需求的分析,意识到原系统中用户大多是被动接受管理和服务,缺乏主动参与和创造的机会。新的社交圈功能允许学生自主创建主题圈,围绕自己感兴趣的话题展开交流,无论是学术讨论、社团活动推广还是日常生活分享都可以。同时,丰富的话题评论和聊天功能极大地增强了用户之间的互动性,激发学生的参与热情,提高用户粘性。

问题 3:原系统信息传播渠道单一,无法满足学生对信息获取和共享的多元化需求。

修改 3:原宿舍管理系统主要通过管理员发布通知等方式传达信息,信息传播范围有限且形式单一。在社交圈功能中,学生可以发布话题,信息传播更加灵活和广泛。例如,校园内的各种活动信息、学习资料分享、二手物品交易等都可以通过话题发布迅速传播给关注相关主题圈的同学,实现信息的高效共享和快速流通,让学生能更及时、全面地获取所需信息。

(二)与目标用户沟通及需求理解

为深入了解目标用户对新社交圈功能的需求,我们开展了一系列调查活动。

1. 用户调查过程

  • 线上调研问卷:在学校官方网站、学生微信群和 QQ 群等渠道发布问卷,共收集有效问卷 [133] 份。问卷内容涵盖学生对社交平台的使用习惯、期望在宿舍社交圈中获得的功能、对不同类型话题的兴趣程度以及对信息交流方式(如文字、语音、图片、文件)的偏好等方面。例如,问卷结果显示大部分学生每天都会使用社交平台,希望在宿舍社交圈中能够便捷地找到与自己兴趣相同的同学,对学习交流、兴趣爱好分享等话题关注度较高,并且希望能够通过语音和图片等方式更生动地表达自己的想法。

  • 线下深度访谈:组织了多场线下访谈,邀请了不同专业、年级和性格特点的学生参与。在访谈中,引导学生分享他们在校园生活中的社交场景和遇到的问题,以及对新社交圈功能的具体设想。比如,有学生提到在参加社团活动时,希望能通过社交圈快速找到合作伙伴;还有学生表示希望能在平台上分享自己的旅游经历和美食体验,但目前缺乏合适的渠道。

  • 竞品分析与借鉴:研究了市场上热门的社交平台(如微信、QQ 空间、豆瓣小组等)以及其他校园社交产品,分析它们的功能特点、用户交互设计、信息传播机制等,取其精华去其糟粕,为我们的宿舍社交圈功能设计提供参考。例如,借鉴微信的聊天界面简洁易用性,参考豆瓣小组的主题圈分类和管理模式,使我们的系统更符合学生的使用习惯。

2. 目标用户的痛点和场景分析

(1)学生方面

  • 痛点:

    • 社交圈子狭窄:在校园中,学生主要社交圈子局限于班级和社团,难以结识其他专业和年级的同学,限制了人际关系的拓展和信息的获取。

    • 缺乏校园信息整合平台:各类校园信息分散在不同渠道,如公告栏、班级群、社团公众号等,学生需要花费大量时间和精力去筛选和查找自己感兴趣的信息,容易错过重要信息。

    • 交流方式受限:在与同学交流时,现有渠道(如班级群聊)往往不能满足多样化的交流需求,如分享图片、语音讲解复杂问题等不够便捷,影响交流效果。

  • 场景(使用前):小张是一名大一新生,对学校的各种社团活动充满兴趣,但除了参加班级组织的招新宣传外,很难获取其他社团的详细信息,不知道如何加入自己喜欢的社团。在学习上遇到难题时,只能在课间有限的时间内向周围同学请教,交流方式局限于口头讲解,对于一些复杂的解题思路和参考资料无法有效分享。

  • 场景(使用后):小张进入宿舍社交互动平台后,通过搜索 “社团活动” 主题圈,找到了学校所有社团发布的活动信息,包括详细的活动介绍、报名方式和以往活动照片等,顺利加入了心仪的摄影社团。在学习过程中,他在 “学习交流” 主题圈发布了自己遇到的难题,并附上图片说明,很快就收到了不同专业同学的语音解答和相关学习资料推荐,问题得到了有效解决,同时还结识了许多志同道合的朋友,拓展了自己的社交圈子。

(2)管理员方面

  • 痛点:

    • 管理难度大:在传统的宿舍管理模式下,对于学生在校园内自发形成的社交活动和信息传播难以进行有效的监管和引导,容易出现信息混乱和不良影响。

    • 缺乏学生需求洞察渠道:无法及时了解学生在社交方面的需求和问题,难以为学生提供针对性的服务和支持,不利于营造良好的校园氛围。

  • 场景(使用前):王管理员在处理学生事务时,经常会听到一些关于校园内未经证实的消息传播,但由于缺乏有效的管理工具和信息来源,无法及时制止和澄清,给校园管理带来了一定困扰。同时,在组织校园文化活动时,由于不了解学生的兴趣偏好,活动参与度不高,效果不理想。

  • 场景(使用后):王管理员通过宿舍社交互动平台的管理员后台,可以实时监控校园圈话题,对不实信息及时进行审核和处理,发布官方通知进行澄清和引导,有效维护了校园秩序。同时,通过分析学生在平台上创建的主题圈和发布的话题,了解到学生对音乐、体育等方面活动的强烈兴趣,为后续组织校园文化活动提供了重要参考,提高了活动的针对性和参与度。

二、系统设计

(一)架构设计

本系统采用微服务架构,以更好地满足新增社交圈功能后的复杂需求和实现系统的可扩展性。

  • 用户服务:负责用户的注册、登录、信息管理以及权限认证等功能。该服务独立维护用户数据,确保用户信息的安全性和一致性。例如,在用户登录时,用户服务验证用户名和密码的正确性,并根据用户角色(普通学生、管理员)分配相应的权限,同时提供找回密码、修改个人信息等功能接口。

  • 社交圈服务:专注于社交圈相关功能的实现,包括主题圈的创建、管理,话题的发布、审核、展示以及评论功能等。社交圈服务与其他服务(如用户服务、消息服务)进行交互,实现用户在社交圈中的各种操作。比如,当学生创建一个主题圈时,社交圈服务会验证用户权限,然后在数据库中创建相应的主题圈记录,并通知消息服务向关注该主题圈类型的用户推送创建消息。

  • 消息服务:处理系统内的各种消息推送和通知功能,如话题评论提醒、聊天消息发送与接收、系统公告推送等。消息服务采用异步通信机制,确保消息的及时传递,同时能够根据用户的在线状态和设置进行智能推送。例如,当有新的话题评论时,消息服务会根据评论接收者的设置(如是否接收提醒、接收方式等),通过站内信、手机推送等方式及时通知用户。

  • 存储服务:负责存储系统中的各类数据,包括用户数据、社交圈数据(主题圈信息、话题内容、评论等)、文件数据(用户上传的图片、文件等)。存储服务采用分布式文件系统和关系型数据库相结合的方式,以满足不同类型数据的存储需求,确保数据的高可用性和可扩展性。例如,用户头像等图片文件存储在分布式文件系统中,而用户信息、社交圈关系等结构化数据则存储在关系型数据库中。

各微服务之间通过轻量级的 API 进行通信,采用 RESTful 风格的接口设计,便于不同服务之间的数据交互和协作。这种架构设计使得每个服务可以独立开发、部署和扩展,提高了系统的灵活性和可维护性。

(二)数据库设计

数据库设计如下:

  • 用户表(user):

    • 用户 ID(user_id,主键)

    • 用户名(username)

    • 密码(password)

    • 角色(role,如管理员、普通学生)

    • 联系方式(contact_info)

    • 个人简介(profile_description)

  • 主题圈表(circle):

    • 圈子 ID(circle_id,主键)

    • 名称(name)

    • 描述(description)

    • 创建者 ID(user_id,外键,关联用户表)

    • 创建时间(create_time)

    • 圈子类型(circle_type,如学习、兴趣爱好、生活等)

  • 话题表(topic):

    • 话题 ID(topic_id,主键)

    • 标题(title)

    • 内容(content)

    • 发布时间(publish_time)

    • 发布者 ID(user_id,外键,关联用户表)

    • 所属圈子 ID(circle_id,外键,关联主题圈表)

    • 审核状态(status,如待审核、已通过、未通过)

  • 评论表(comment):

    • 评论 ID(comment_id,主键)

    • 评论内容(comment_content)

    • 评论时间(comment_time)

    • 评论者 ID(user_id,外键,关联用户表)

    • 话题 ID(topic_id,外键,关联话题表)

  • 聊天记录表(chat_record):

    • 记录 ID(record_id,主键)

    • 发送者 ID(sender_id,外键,关联用户表)

    • 接收者 ID(receiver_id,外键,关联用户表)

    • 消息内容(message_content)

    • 发送时间(send_time)

  • 文件表(file):

    • 文件 ID(file_id,主键)

    • 文件名称(file_name)

    • 文件路径(file_path)

    • 文件类型(file_type)

    • 所属话题 ID(topic_id,外键,关联话题表,若为聊天文件则关联聊天记录表)

通过以上数据库设计,各个表之间通过外键关联,形成了完整的数据关系模型,能够支持系统对用户信息管理、社交圈操作、话题交流以及文件存储等功能的实现,确保数据的完整性、一致性和高效检索。

三、Alpha 任务分配计划

(一)功能项选取

依据项目组的时间、资源以及功能模块的优先级和依赖关系,在 Product Backlog 中选取以下功能项作为 Alpha 阶段的重点:

  • 用户注册与登录功能完善:优化用户注册流程,增加多种注册方式(如手机号注册、邮箱注册),并完善登录功能,支持密码找回、记住密码等,确保用户能够顺利进入系统,为后续功能使用奠定基础。

  • 主题圈创建与管理功能实现:开发学生创建主题圈的功能,包括圈名、描述、类型等信息的设置,同时实现管理员对主题圈的审核(若需要)和管理(如关闭、推荐等)功能,初步构建社交圈的框架。

  • 话题发布与展示功能开发:允许学生在主题圈内发布话题,包括文字、图片等内容,实现话题在相应主题圈和校园圈(若符合条件)的展示,以及话题详情页面的展示功能,让学生能够分享信息和发起交流。

(二)任务分解

将选取的功能项进一步分解为 1 - 10 小时左右的任务,构成 Sprint Backlog:

  • 用户注册与登录功能完善:

    • 设计用户注册界面的优化方案(3 小时)

    • 开发手机号注册功能后端接口(5 小时)

    • 实现邮箱注册功能及验证逻辑(6 小时)

    • 优化登录界面交互设计(3 小时)

    • 开发密码找回功能(4 小时)

    • 实现记住密码功能(3 小时)

  • 主题圈创建与管理功能实现:

    • 制定主题圈创建的数据验证规则(4 小时)

    • 开发主题圈创建功能的前端页面(6 小时)

    • 设计主题圈审核的管理员界面(4 小时)

    • 实现主题圈审核的后端逻辑(5 小时)

    • 开发主题圈管理功能(如关闭、推荐等操作的后端接口)(6 小时)

  • 话题发布与展示功能开发:

    • 设计话题发布界面,支持文字和图片上传(5 小时)

    • 开发话题发布功能的后端服务(7 小时)

    • 实现话题在主题圈和校园圈的展示逻辑(5 小时)

    • 开发话题详情页面的前端展示(6 小时)

(三)任务认领与甘特图拟定

在 PM 的协助下,编码的同学对任务进行认领。以下是 7 天 Alpha 阶段的迭代冲刺计划甘特图:

任务名称 开始时间 结束时间 负责人
用户注册与登录功能完善
设计用户注册界面的优化方案
[2024-11-9] [2024-11-9] 洪吉潮
用户注册与登录功能完善
开发手机号注册功能后端接口
[2024-11-7] [2024-11-7] 刘家辉
用户注册与登录功能完善
实现邮箱注册功能及验证逻辑
[2024-11-8] [2024-11-8] 刘家辉
用户注册与登录功能完善
优化登录界面交互设计
[2024-11-9] [2024-11-9] 洪吉潮
用户注册与登录功能完善
开发密码找回功能
[2024-11-9] [2024-11-9] 刘家辉
用户注册与登录功能完善
实现记住密码功能
[2024-11-9] [2024-11-9] 刘家辉
主题圈创建与管理功能实现
制定主题圈创建的数据验证规则
[2024-11-10] [2024-11-10] 刘家辉
主题圈创建与管理功能实现
开发主题圈创建功能的前端页面
[2024-11-9] [2024-11-10] 洪吉潮
主题圈创建与管理功能实现
设计主题圈审核的管理员界面
[2024-11-10] [2024-11-10] 洪吉潮
主题圈创建与管理功能实现
实现主题圈审核的后端逻辑
[2024-11-11] [2024-11-11] 刘家辉
主题圈创建与管理功能实现
开发主题圈管理功能(如关闭、推荐等操作的后端接口)
[2024-11-12] [2024-11-12] 刘家辉
话题发布与展示功能开发
设计话题发布界面,支持文字和图片上传
[2024-11-15] [2024-11-15] 洪吉潮
话题发布与展示功能开发
开发话题发布功能的后端服务
[2024-11-13] [2024-11-13] 刘家辉
话题发布与展示功能开发
实现话题在主题圈和校园圈的展示逻辑
[2024-11-14] [2024-11-14] 刘家辉
话题发布与展示功能开发
开发话题详情页面的前端展示
[2024-11-15] [2024-11-15] 洪吉潮

通过合理的任务分配和详细的计划安排,项目组将在 Alpha 阶段有序推进系统开发,重点实现社交圈的关键功能,为后续迭代优化和功能拓展做好准备,同时注重收集用户反馈,持续改进系统以满足用户需求。

四、测试计划

  1. 任务概述

本测试计划旨在为新开发的宿舍管理系统、进行全面的测试,以确保其满足既定的功能需求、性能标准、安全性要求及兼容性标准。测试将覆盖所有新开发的功能点,并进行必要的非功能测试,以保障产品的质量和用户体验

2.1 测试范围

  • 2.1.1 功能测试:覆盖所有新开发的功能点,包括但不限于用户注册与登录、主题圈创建与管理、话题发布与展示等。

  • 2.1.2 非功能测试:

  • 性能测试:评估系统在高负载下的响应时间、吞吐量等。

  • 安全性测试:检查系统是否存在安全漏洞,如SQL注入、XSS攻击等。

  • 兼容性测试:确保应用在不同设备、操作系统和浏览器上的表现一致。

2.2 测试目标

  • 确保所有功能按预期工作,无严重缺陷。

  • 验证系统的性能、安全性和兼容性满足既定标准。

  • 提供详细的测试报告和缺陷记录,以供开发和产品团队参考。

  1. 测试策略

3.2 测试方法

  • 自动化测试:使用Selenium或类似工具进行自动化测试,以提高测试效率。

  • 手动测试:针对复杂或难以自动化的测试场景进行手动测试。

  • 白盒测试:由开发人员进行的内部测试,关注代码逻辑和内部状态。

  • 黑盒测试:从用户角度进行的测试,不关心内部实现,只关注输入输出。

  • 中断测试:模拟系统在异常情况下的表现,如网络中断、电源故障等。

  • 临界测试:测试系统在接近其处理能力极限时的表现。

  • 压力测试:通过模拟大量用户同时访问来测试系统的稳定性和性能。

3.2.1 用户注册与登录

  • TC1: 使用有效手机号注册,验证注册成功并能正常登录。

  • TC2: 使用无效手机号注册(如格式错误、已存在等),验证注册失败并给出正确提示。

  • TC3: 使用有效邮箱注册,验证注册成功并能正常登录。

  • TC4: 使用无效邮箱注册(如格式错误、已存在等),验证注册失败并给出正确提示。

  • TC5: 使用手机号登录,验证登录成功并能访问用户主页。

  • TC6: 使用邮箱登录,验证登录成功并能访问用户主页。

  • TC7: 密码找回功能,验证通过邮箱或手机号找回密码的成功率。

  • TC8: 记住密码功能,验证在不同设备上的表现。

3.1.2 主题圈创建与管理

  • TC9: 创建主题圈并验证数据规则(如名称长度、描述内容等)。

  • TC10: 管理员审核主题圈,验证审核通过和拒绝的不同情况。

  • TC11: 主题圈管理操作(关闭、推荐),验证操作成功后的系统状态。

3.1.3 话题发布与展示

  • TC12: 发布包含文字的话题,验证发布成功并能在指定圈子展示。

  • TC13: 发布包含图片的话题,验证图片上传、存储和显示的正确性。

  • TC14: 话题在不同圈的展示,验证话题在不同圈子中的可见性和展示效果。

  • TC15: 话题详情页面展示,验证页面内容、布局和交互的合理性。

3.2 工具引用及测试培训(内训/外训)

  • 引用Selenium、JMeter或其他工具进行自动化测试和性能测试。

  • 组织内部培训,提高测试团队对测试工具和方法的理解和应用能力。

3.3 测试阶段计划(工作内容、人员安排、起止时间等)

  • 工作内容:需求评审、测试用例设计、测试环境搭建、自动化脚本编写、测试执行、缺陷跟踪和回归测试等。

  • 人员安排:明确测试经理、测试工程师、自动化测试工程师等角色及其职责。

  • 起止时间:根据项目进度表制定详细的测试时间计划,包括测试准备、执行、总结和报告等阶段。

3.4 测试停止及恢复条件

  • 停止条件:达到测试目标,无严重缺陷遗留,测试资源耗尽等。

  • 恢复条件:缺陷修复完毕,测试环境恢复,测试资源重新分配等。

3.5 测试文档及缺陷提交管理等

  • 编写测试计划、测试用例、测试报告等文档。

  • 使用缺陷跟踪系统(如Jira、Bugzilla等)提交和管理缺陷。

3.6 测试环境

  • 硬件环境:服务器配置、存储设备、网络设备等。

  • 软件环境:操作系统Linux、数据库MySq、中间件、应用服务器等。

  • 网络环境:模拟不同网络带宽、延迟和丢包情况。

  • 数据环境:准备测试数据,包括用户信息、主题圈信息、话题信息等。

  1. 其他内容

除以上内容有关项外,还要包括测试计划制定者、日期、修改记录、评审人员(开发负责人/测试负责人/项目经理)等信息

  • 测试计划制定者:柳浩

  • 日期:11月15日后

  • 修改记录:记录测试计划的修改历史,包括修改时间、修改内容和修改人。

  • 评审人员:开发负责人、测试负责人、PM等,确保测试计划的合理性和可行性。

posted @ 2024-11-07 16:36  u1u1uu1  阅读(25)  评论(0编辑  收藏  举报