Skip to content

Latest commit

 

History

History
152 lines (111 loc) · 6.73 KB

20141013.md

File metadata and controls

152 lines (111 loc) · 6.73 KB

实验班图书采购及管理应用需求说明书

需求的产生

背景

  • 实验班成立了购书基金，拟构建图书馆，围绕图书形成学习社区。
  • 第一期推荐购书活动，采用专人负责，QQ群交流的方式，遇到如下困难。

困难

  • 推荐不方便
    • 难以列出图书的相关资源，不能令大家充分了解目标图书，比如图书链接、书评、相关附件、学习资源等。
    • 作为教师，看不到同学们推荐的理由（为何要买此书，围绕该书的学习计划为何），无法给出意见和评价
  • 决策不方便
  • 缺乏有效的决策手段，即决定最终的书籍清单，尤其是公共图书，如何进行投票？
  • 如何高效的发现最经济的购买方案，可否有类似豆瓣的比价功能？自动预算功能等？
  • 管理不方便
  • 如何管理图书这一公共资产，譬如图书登记、去向跟踪、借阅统计等等？
  • 如何充分发挥图书的使用效率，即围绕图书形成学习社区，譬如图书的阅读心得、扩展阅读等

扩展

  • 图书的来源，可否来自于旧书收购（如上届）、师生的捐赠或暂存、其它来源等
  • 与电子图书的互补
  • 未来直接与各主流网站打通

其它

  • 有同学上QQ群少，当需要民主参与时，不能及时反馈意见，如何处理？

用户故事（外部角度）

图书购买场景

用户：教师、学生 系统角色：购买活动负责人、推荐人、评价人

  • 推荐人在当当网等主要购书网上浏览图书，点击浏览器上的某书签，即自动跳转到当期的图书推荐页面，且自动填 充该页面上的主要信息，推荐人只需填写推荐理由、推荐类别等即可

    • 推荐人可推荐两类图书
      • 一类是自选必读，自动成为该图书学习社区的版主。每一期购买活动，一般只允许推荐固定的本数。
      • 一类是推荐入库，为公共图书。推荐的数量灵活，视当期的预算而定。

  • 师生查看推荐的图书，可了解如下基本信息

  • 该书的书名、作者、出版年月等基本信息；

  • 该书详细信息的链接；

  • 书评的链接，如豆瓣或其它站点

  • 自动搜索电子书的链接

  • 自动比价

  • 推荐人添加的信息

  • 评分、留言等信息

  • 推荐人对自选的推荐书，可编辑和添加如下信息：

  • 自己的学习心得

  • 精采书评链接

  • 该书的附件资源，如随书代码等

  • 该书的相关学习资源,如PPT、在线课程等等

  • 师生对推荐的图书

    • 如支持，可顶+1分，以方便未来统计；
    • 可留言。

  • 购书活动负责人可发起购书活动，需要提交以下信息

  • 活动类型，即自选，还是公共图书

  • 活动截止日

  • 预算上限

  • 其它需要说明的信息

  • 购书活动负责人可查看图书推荐情况的统计信息

  • 自选图书清单，可按学号、书名等搜索

  • 公共图书清单，可按评分、价格等排序

  • 以上清单的自动总价汇总，按各主流网站的价格及优惠分别统计

  • 购书活动负责人可关闭当期购书活动

    • 确认最终的图书清单，填写实际的购买花费
    • 生成最终的图书统计信息文档（静态网页或PDF），同时附上购买截图等相关资料，作为本次购买活动的总结。

图书管理场景

用户：教师、学生 系统角色：图书管理员、借阅人

  • 图书管理员查看已购买的图书清单，执行入库操作后，可借阅。
  • 图书管理员查看未编码的入库图书清单，可单个或批量生成二维码(QRcode)，并输出打印
  • 借阅人借阅时，使用自己手机上的客户端，对目标图书的二维码进行扫描，返回成功提示后，即可将图书借出。
  • 借阅人归还时，由管理员用自己手机上的客户端，对目标图书的二维码进行扫描，返回成功提示后，即为图书还入
  • 借阅人可查看自己的当前借阅记录与历史统计信息
  • 管理员可查看图书的借阅等各类统计信息

班级签到与消息通知场景

用户：教师、学生 系统角色：管理员、通知者、接收者、签到者

规则：

  • 每个用户必须每天签到一次（签到的时间段、频率等？？），以确保接受到班级信息，且作为班级虚拟考勤的依据

  • 必须作为手机开机自启应用（意味着支持推送）

  • 签到者打开手机上的客户端，点击签到或成功查看任一未读消息，即视为成功签到

  • 通知者发送消息：填写消息标题，消息内容，选择是否需要回执，选择发送范围（全体或个别）。然后发送。

  • 接收人打开手机上的客户端，查看消息提示列表，点击查看消息详细。

  • 如需要回执的，必须先确认收到后，方可查看消息详细。

  • 通知者可查看到消息的接收信息统计

  • 是否已读、读取时间

  • 接收者的签到时间

  • 管理员可查看到各类信息统计：如签到情况、消息发送情况等

系统故事（内部角度）

思考

  • 上述需求有关图书信息获取，除使用爬虫方式外，是否可使用WEB API方式，什么是WEB API,有何优势与限制？
  • 上述需求，可否不使用自行编写系统的方式解决，譬如，使用一系列的互联网工具及小的脚本？

项目模拟

团队结构

  • 客户代表：代表师生制订规则，提出需求，并验收项目。1人
  • 产品经理：负责搜集、整理和分析客户提出的需求，整理成文档，如需求说明书或用户故事集。1人
  • 项目经理及技术负责人：负责根据需求文档，确定系统架构和关键技术，分解任务，计划日程，跟踪和控制开发进度。1人 度。1人
  • 开发人员：负责具体模块的设计与开发。1-2人
  • 实习生：资料搜集、小程序编写、打杂。不限