1 Star 0 Fork 0

孙嘉伟/小组任务专用仓库

加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
该仓库未声明开源许可证文件(LICENSE),使用请关注具体项目描述及其代码上游依赖。
克隆/下载
README.md 8.78 KB
一键复制 编辑 原始数据 按行查看 历史
孙嘉伟 提交于 2019-12-01 21:39 . update README.md.

目录

1.引言

2.项目概述

3.具体需求

4.验证验收标准及相关需求

1. 引言

1.1 编写目的

  • 经过一个学期的java学习与Android的学习,我们需要清楚地了解自身知识的掌握程度与运用能力,于是我们在老师的引导和推荐下开始了此次做程序的实践任务。

  • 进入计算机时代后可以通过计算机解决一些较为麻烦的事情。通过对java的学习可以做一些在日常生活中较为繁琐的事情。生成数字计算器可以帮助一些儿童学习数学知识,同时新颖的教学方式可以激发其学习兴趣。因此,我们团队初步计划做一个简易计算器以刺激小学生学习兴趣.

  • 本文档面向的预期读者范围与阅读建议:

  • 项目经理:项目经理根据该文档了解预期产品的功能,并据此进行系统设计、项目管理。

  • 程序员:了解需求的程序特点与系统功能。

  • 测试员:根据本文档作出测试用例,对软件进行功能性测试与非功能测试。

  • 用户:清晰了解软件使用方式

1.2 项目背景

  • 项目开发单位:北京电子科技学院-2018级23班- 男儿当志强团队
  • 通过对java的学习可以做一些在日常生活中较为繁琐的事情。生成数字计算器可以帮助一些儿童学习数学知识,同时新颖的教学方式可以激发其学习兴趣。

1.3 参考资料

  • 《报课系统软件需求规格说明书》
  • 《报课系统需求规格说明书》
  • 《一起买APP需求规格说明书》

2. 项目概述

2.1 产品描述

  • 生成数字的计算器可以帮助一些儿童学习数学知识,同时新颖的教学方式可以激发其学习兴趣。因此,我们团队初步计划做一个简易计算器以刺激小学生学习兴趣

2.2 产品功能

  • 功能介绍 该程序功能为自定义题目数量,随机生成该数量道计算题(加减乘除),用户输入答案,在所有题目计算完成后显示正确率,并提示是否继续。

2.3 用户特点

本产品可使用于一切能独立使用Android手机的用户,针对需要练习四则运算的学生。

2.3.1 用户场景

用户场景A:小荷是一名小学生,周末放假回家闲来无事,想玩游戏,于是拿起手机开始学做JAVA编写的数学题训练游戏。 用户场景B:小王是一个学生,上午上了半天学有点累,中午休息的时候想要提高,于是拿出了手机开始练习数学题。

2.3.2 用户需求分析

场景A:用程序做数学题比较新潮,可以尝试练习。 场景B:数学题很有趣味性,而且也不会占用太多时间,还可以益智。

2.3.3 用例图

2.3.4 用例说明

用户在点击该APP时,首先会出现一个选择生成算式数量的界面。选择后将会出现欢迎。欢迎后可以选择开始计算那和退出计算器界面,开始计算后可进行计算,全部计算完成后输出正确率。

2.4 假定和约束

2.4.1 假定

  • 1.可操作性:假定本游戏用户在试用时可以正常输入并获得结果。
  • 2.用户支持:假定在本程序开发的各个环节中得到用户的有效支持和配合。
  • 3.技术支持:假定开发初期,小组成员成分认识程序的需求,认真学习相关知识。假定在开发过程中遇到问题,可以及时得到老师的指导与帮助。
  • 4.人员配合:假定小组成员不会出现变动,并且在项目开发过程中不会有突发情况的发生而导致项目成员无法正常参与开发工作。
  • 5.时间限定:假定项目的截止时间不会提前。
  • 6.需求限定:假定项目需求基本确定之后,不会有太大改变。

2.4.2 约束

  • 人员约束: 团队成员均为大二学生,共5人。
  • 管理约束:1.本次开发,实行以一人担任小组组长,各组员分工合作的模式进行。每个人负责切实具体的流程板块,并且按照进度表进行,开发过程中遇到的问题通过小组会议得到一致的解决。 2.小组成员首次合作,需要明确责任,互相配合,迅速度过磨合期。在遇到问题时需要小组组长能进行有效的协调,才能快速,有效地完成开发过程。
  • 技术约束:1、小组成员在相关技术水平方面存在一定欠缺,缺乏相关项目经验,在文档编制能力方面也有待提升。 2、小组成员在美工方面,能力有限。
  • 时间约束: 本系统开发周期较短,时间相对紧张。 其他约束: 由于在开发期间,小组成员还有其他科目的学习任务,将对项目进度造成一定的影响。

3.具体需求

3.1 功能需求

3.1.1 界面设计

  • 我们小组初定为基础界面,后续组长会根据时间不断对程序界面进行优化升级,尽请期待。

3.2 外部接口需求

3.2.1 用户接口

无特殊需求。

3.2.2 硬件接口

无特殊需求。

3.2.3 软件接口

调用计算器。

3.2.4 通信接口

无特殊需求。

3.3 性能需求

3.4 属性

3.4.1 可用性

  • 1.易操作,易理解。界面设计简洁易用。
  • 2.操作完成时有统一规范的提示信息。

3.4.2 可维护性

  • 1.保留系统的源代码
  • 2.代码注释详细,包括方法实现过程以及变量的含义。
  • 3.清晰的系统结构和命名规范,界面规范。
  • 4.每次调试都会记入日志。
  • 5.不断从各方面操作进行测试。

4. 验证验收标准及相关要求

4.1 验收标准

4.1.1 文档验收标准

  • (1)app项目开发计划
  • (2)软件需求说明书
  • (3)团队项目及时记录和总结报告(团队博客)

4.1.2 软件验收标准

  • APP安装包

4.1.3 界面验收标准

4.1.4 功能验收标准

4.1.5 程序验收标准

4.2 灵活性

本软件最终完成后,短期内需求不会发生太大变化。相应地,即当需求发生某些变化时,该软件具备对这些变化的适应能力:本系统的操作方式相对简单,用户可以很容易掌握。 在系统前期的需求分析和交互设计方面已经做了充分的考虑和设计,一般不会发生太大的变化。不过我们可以根据用户需求的变化,做一些更改和扩充,具有比较好的扩展性。

4.3 时间特性需求

此APP对时间特性有一定要求,需要据此生成随机数。

4.4 其它要求

  • 安全要求: 不向用户索要个人信息,确保用户在使用该APP的安全性。
  • 可靠性:

系统具有较强的稳定性,不存在太多的不稳定因素。

  • 使用方便要求:

(1)该系统的所有界面要简洁且易懂。

(2)操作完成时有统一规范的提示信息。

  • 可维护性

(1)保留系统的源代码。

(2)代码注释详细,包括方法实现过程以及变量的含义。

(3)清晰的系统结构和命名规范,界面规范。

(4)每次调试都会记入日志。

(5)全面考虑系统,加强后期的维护,不断从各方面操作进行测试。

  • 性能需求:

(1)需要调用用户系统中的计算器。

马建仓 AI 助手
尝试更多
代码解读
代码找茬
代码优化
1
https://gitee.com/water_mirror/team_task_specific_warehouse.git
git@gitee.com:water_mirror/team_task_specific_warehouse.git
water_mirror
team_task_specific_warehouse
小组任务专用仓库
master

搜索帮助

344bd9b3 5694891 D2dac590 5694891