五月阿常五月阿常12-03 06:54

软件工程大作业-第6组-需求分析报告

软件工程大作业-需求分析报告

闪光点

  • 数据流图完备
  • 有ER图
  • 表结构也已经初步定好
  • 需求分析文字内容详实易读
  • 增加了demo

    项目简介

该社团管理系统用于管理zucc的所有社团(不含其他各类学生组织,如学生会,党家等学生组织),面向学生和社团管理者,实现场地调度、社团活动管理和社团人员管理,以及日常的社团管理事务。

数据流图

  • 修改后
    将外部参与方移到了外围,并增加了更多的细节

需求分析

  • 管理员

    • 可进行场地管理
      • 增加新增场地
      • 删除不可用的教室
      • 修改场地信息(如若场地临时无法使用增加备注及修改状态)
    • 可进行活动管理
      • 对社团上报的活动进行审批(地点时间系统自动审批,活动主题人工审批)
      • 对社团提交的修改活动信息申请表进行审批(驳回时间冲突的活动,线下通知社长修改,并告知社长该场地可选择的时间段)
      • 对社团提交的删除活动申请表进行审批
    • 可进行社团管理
      • 学生线下填写创建社团申请,并按社团申请要求准备所需材料,申请通过后,管理员填写基本信息,任命社长(增)
      • 审核社长线下填写解散社团申请,或由管理员主动删除违规社团并通知相关人员(删)
      • 审批社团信息修改申请,第一种情况:修改社团活动室(系统判断冲突),后线下通知社长,第二种情况:换任,在通过线下社长换任申请后修改该社团社长信息,第三种情况:基本信息更改,社团简介等(改)
  • 社长 (由学生转变,学生和社员可见内容,社长仅一个,但账号可供指定人员使用,以解决社长不在而无法处理日常事务时的问题)

    • 可提交社团信息修改申请,分为两类
      • 基本信息修改(线上递交申请表后等待审批)
      • 换任,修改社长信息(线下选举后,社长向管理员递交线下申请表)
    • 可进行社内活动管理
      • 针对需场地调配的活动(如除已安排的活动室外的场地申请)
        • 线上填写表格(场地,时间,活动内容,活动名称,人数限制),提交表格后系统需对场地和时间进行初步判断
      • 针对无需场地调配的社内活动(例会等)
      • 遇到某些不可抗力原因有取消活动的权利(填写取消活动理由向管理员申请审批,若已发布活动公告,则发布取消活动公告)
      • 若存在场地,时间等信息更改需求,可以更改活动信息(向管理员提交更改活动信息申请表,批准后重新发布更改,并删除前活动公告)
    • 可进行社内公告管理
      • 发布公告(填写公告信息表,由社长在活动确定后发布),公告类别分为两类
        • 公开(面向所有学生,可添加活动报名链接)
        • 非公开(面向本社团成员,社内活动,如例会等)
      • 删除公告
    • 可进行社内的社员管理
      • 审批普通学生加入社团的申请(增)
      • 审批社员退出社团的申请,或主动删除违规社员,并通知相关人员(删)
    • 换任(线下选举后,向管理员提交更换社长申请表,等待审批)
  • 社员(由学生转变,可见内容包括本社团公告,社团人员信息(学号,姓名,电话)等)

  • 学生

    • 可以参加公开的活动

      • 提交报名表(包括姓名,学号,联系方式,性别),由社长审批
    • 可以申请加入社团(通过审核后在该社团登记为社员)

    • 可以申请退出社团(通过审核后退出)

    • 修改密码

    • 在系统中的可见内容(所有人可见)包括

      • 公开公告

      • 所有社团基本信息

表结构

  • 学生(学号,姓名,性别,联系方式,密码,状态,备注)
  • 社团(社团编号,社团名称,场地编号,logo,社长编号,简介,状态,备注)
  • 社团人员表(社团编号学号,角色,状态,备注)
  • 活动表(活动编号,活动内容,场地编号,负责人学号,时间,参加人数,社团编号,预算,状态,备注)
  • 活动人员表(活动编号学号,状态,备注)
  • 活动场地表(活动编号场地编号
  • 场地表(场地编号,场地名称,状态,备注)
  • 公告表(公告编号,社团编号,内容,时间,地点,公告类型,状态,备注)
  • ER图

    修改后
    • 修改了学号的varchar长度,增加了备注和活动内容的varchar长度
    • 关于场地和活动之间的多对多或一对多关系这个建议,由于之前定需求的时候,有说要初步判断一下是否和其他活动有场地冲突,所以为了实现这个功能,感觉需要多对多的关系,不然碰到一个活动多个场地的情况会难以判断。进一步沟通之后,还是觉得之前订需求时没有考虑好边界,最后决定场地冲突还是交给外部的审核,于是修改了需求和ER图。简单的一个需求确实会影响后续的表结构,功能实现等,定需求时确实应该更谨慎一些。这次的修改反馈让我们对需求的边界这一抽象的概念有了更具体的了解,对需求的重要性确实有了更深的体会。

原型设计

  • 主页
    主页
  • 社团总览
    社团总览
  • 活动公告
    活动公告
  • 我的社团
    我的社团

  • demo
    根据原型写了demo
    为了减少工作量,套的是现成模板

    组员信息

姓名 学号 本次分工
罗灵洁 31701003 需求讨论、ER图、数据流图
王秋鸿 31701004 需求讨论、数据流图、原型设计
郑诗雨 31701005 需求讨论、文档攥写
郑珂亦 31701373 需求讨论、文档攥写

程序之家二维码

小额赞赏

000
评论

为您推荐