G003-185-09
作者：互联网
计算机科学与工程学院
小组期末报告
2020～2021 学年第 1 学期
| 课程 | 软件需求分析与建模 |
| 课程项目名称 | 学生签到系统 |
| 团队成员 | 谢钰灿 陈思达 |
| 学号 | 1814080902536、1814080902504 |
| 专业班级 | 18软件工程5班 |
| 指导教师 | 董瑞生 |
| 提交时间 | 2020年12月25日 |
目录
(2)发布签到和完成签到要求............................................................................ 18
四.需求分析应有需求测试与改善计划........................................................................... 22
项目需求提案计划书
1.背景
在学校的日常管理中，平时考勤和学生签到情况是一件由为复杂的情况，加上一起学生在家上网学习和现在管理越来越复杂的环境下，学生点名签到系统的出现尤其重要，这一方面，这个系统减少了学生管理的压力，加快了管理的速度，另一方面，这是促进科技发展和符合信息科学发展的科学发展理念
今年由于疫情的情况，学校一度需要停学改为让学生在家中上网课。那么学校中的管理人员就需要在学生上课的时候让学生进行签到，然后再一个一个的进行签到确认。这种流程无疑十分繁琐。特别是近几年来，由于国家政策的调整，我国教育的飞速发展，全国的学校都在进行大规模的扩招，给各地学校的教学管理、学生管理、后勤管理等方面都带来了不少的冲击。其包含的数据量之大，设计的人员面之广，而且需要及时更新，故较为复杂，难以单纯地依靠人工管理，而传统的人工管理模式即不易于规范化，管理的效率也并不高，而我国目前还有大量学校是依靠纸质材料来进行学校日常教学活动的管理，尤其是一些相对落后地区的中小学。这样的管理机制对于日渐增多的学生数量来说显然是远远不够的。那么随着科学技术的不断发展，计算机科学与技术日渐成熟，计算机应用的普及已经进入人类社会生活的各方各面，并发挥着越来越重要的作用。这种传统的手工管理模式必然会被以计算机为物质基础的信息管理方法而取代。
2.项目概述
(1)项目简介
本小组项目的核心功能就是签到系统，学生信息管理和考勤信息系统。其中大部分核心权限都属于教师及以上等级用户。例如管理学生信息，管理考勤信息，发布签到。
学生用户在本系统的主要功能就是查看当前正在进行中的签到并且进行签到，查看过往的签到，检查自己以往的签到情况，以及修改自己的个人信息。
而教师用户在本系统中的主要功能就是编辑签到信息并且发布，发布之后能够实时查看被发布班级的同学签到情况并对其进行修改处理。
而管理员用户为最高权限拥有者，拥有包括教师权限在内的所有权限，能够进行发布签到，发布编辑公告在内的所有活动。
Organization Chart
适用环境：用户或者客户不理解本系统的角色安排时
使用目的：本图直观展示了项目的角色分配以及层次结构，能使读者对本项目有一个直观的理解。
绘制步骤：对用户进行需求分析，细分出学生，教师和管理员三大角色以及三个角色的细分。
图例说明：上图为本系统的角色组织结构图，让用户能够直观理解，也让开发人员更容易对本项目进行开发。
(2)目的
本项目作为计算机应用的一部分，使用计算机对学校的日常教学活动考勤进行管理，有着传统依靠纸质材料管理所无法比拟的优点，如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等等。这些优点能够极大的提高日常教学活动管理的效率，也是学校向科学化、正规化管理发展的必要条件，更是各个高等院校与世界接轨的重要条件。
上课点名签到系统为用户提供了相当便捷的日常教学管理操作，方便教师对授课班级日常的出勤情况进行管理。学生也可以在本系统对自身平时的考勤情况进行查看。可谓大幅度的降低的学校的日常工作量。
参考资料
[1]骆斌.需求工程——软件建模与分析[M].南京.高等教育出版社.2015:504
- 项目需求萃取分析书
(1)目的
从人员、资料和环境中得到系统开发所需要的相关信息，对项目进行需求收集。对用户和开发人员的背景不同，立场不同的环境中，解决他们之间的知识理解的困难，开发人员清楚并完整地获取用户的需求，清楚地理解所要解决的问题。到后面找出其的问题域以及要分析的内容。
(2)项目前景与范围
在互联网高速发展的今天，线上教学相对于传统教学的优势显然也在逐步显现出来。相比于传统的教学模式，线上教学在人工和时间上花费的成本很明显要比传统的教学模式更低。因此，线上点名系统的需求就日益增长，由此可见，我们开发的上课点名签到系统的前景可谓十分广阔。上课点名签到系统当前运用的范围也十分广泛，随着国家教育事业的发展，国内中小学进行大规模的扩招，学校对于日常行政管理的信息化需求会日渐增加。而且市面上目前也已经有相当多成熟的软件了，例如：钉钉，学习通，蓝墨云班课等等……我们的项目就是模仿目前市面上已经成熟的管理软件来进行设计。
(1) 针对涉众
本项目可为普通初中、高中进行服务，进行一些简单的改进也可以为大学进行服务。
项目涉众包括：
客户（学校管理员）：为达到其公司的业务目标而投资项目或购买产品。
用户（学生和教师）：直接或间接与产品打交道，是客户的一部分。
管理员：对公司进行人事业务管理，管理员以管理员权限登录系统，录入老师和学生信息，管理增添、修改、删减老师和学生信息
学生：了解学校内部信息以及请示自身要求，学生以用户权限登录系统，查看学生的通信方式已经查看自身信息和修改自身信息。
涉众概要
| 涉众名称 | 涉众说明 | 使用系统方式 |
| 普通学生 | 普通学生能使用本系统进行正常的登录账号与签到 |
|
| 学校教师 | 学校教师是学校在进行日常教学活动时签到活动的发布者 |
|
| 管理员 | 管理员是指学校对系统进行日常管理的人员 |
|
涉众简档
| 涉众代表 | 学生 | 教师 | 管理员 |
| 特点 | 系统的主要使用者之一 | 系统的主要使用者之一 | 系统的建设与维护者 |
| 使用功能 | 进行日常签到 | 进行签到发布 | 能够进行学校的管理 |
| 成功标准 | 能正常的使用签到功能并进行考勤 | 能正常发布签到，并在签到后能够查看班级的考勤情况 | 能够对学校的课程，学生教师的账号进行管理 |
| 参与 | 不参与系统实现 | 不参与系统实现 | 参与系统的维护与一部分实现 |
（3）明确问题
| 要素 | 内容 |
| ID | P1 |
| 提出者 | 签到管理员 |
| 关联者 | 老师，校长 |
| 问题 | 学校规模庞大，教学管理效率低下 |
| 影响 | 正常教学秩序混乱 |
| 要素 | 内容 |
| ID | P2 |
| 提出者 | 教师 |
| 关联者 | 教师和学生 |
| 问题 | 纸质签到效率低下 |
| 影响 | 日常教学活动的进行收到影响 |
| 要素 | 内容 |
| ID | P3 |
| 提出者 | 教师 |
| 关联者 | 教师和学生 |
| 问题 | 网上课堂性质导致学生参与积极性不高 |
| 影响 | 学生出勤率低下 |
| 提出者 | 教师 |
(4)业务需求
1：系统可以满足校方管理学生的需要
2：教师在学校进行正常教学活动时可以发布签到
3：学生能够通过本系统完成签到
(5)解决方案
| 要素 | 内容 | |
| ID | P1 | |
|
解决方案1 | 方案描述 | 提供一个简便的签到方案，提升学校师生使用体验 |
| 业务优势 | 相比其他签到系统提供了一种较为便捷的签到形式 | |
| 代价 | 无 | |
|
解决方案2 | 方案描述 | 准确的资料管理，提供实时的分析数据，在发布板分布实时数据 |
| 业务优势 | 学生能够实时查看数据 | |
| 代价 | 增加工作量 | |
|
解决方案3 | 方案描述 | 公开部分数据，学生可在系统中随时查看 |
| 业务优势 | 减少管理人员工作量，增加工作效率 | |
| 代价 | 无 |
Use Case Model
适用环境：用户、客户对开发人员举例的解决方案不太理解。
使用目的：系统描述了问题解决方案的内容，描述外部角色在与解决方案的交互中完成的任务与目标；同时从系统特性中抽取，找到系统特性中蕴含的外部角色及交互任务。
绘制步骤：通过问题域、涉众上进行获取问题和明确问题，对发现的每个问题进行“明确问题→发现业务需求→定义问题解决方案及系统特性”，得到每个问题的业务需求和解决方案，从而进行绘制用例图。
图例说明：上图为本系统最常见的使用场景用例，即老师在上课时发布签到，而学生同样在上课时间登录本系统完成签到。老师可以实时查看学生的签到情况。并且在签到完成后查看本节课本班级的出勤情况并对相关学生进行管理。
(2)业务过程分析
不管是老师，管理员和学生都觉得学校的传统管理学生签到的信息存在在较大的问题，如不方便，不快捷，信息存在较大误差等。有许多学生和老师使用过学生签到管理类软件，其他人没使用过，且绝大多数人是会尝试信息管理类软件的，说明信息管理类软件有进一步普及的空间。理想中的信息管理软件特点里简洁轻量、易于上手和精准快捷最为用户看重，许多用户也提出了自己期望的功能，其中激励功能、小目标模板期望较多，在开发过程中在有余力的情况下可以考虑实现。
Activity Diagram
适用环境：从活动到活动的控制流。
使用目的：对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。
绘制步骤：根据功能步骤，查看活动，动作完成后通过完成转换转向另一个状态。
图例说明：管理员从登录的活动进入到管理系统活动，对员工进行三个活动操作，分别时添加员工、删除员工和查看员工，查看员工活动有着员工属性。
3.项目前景与可行性
在互联网高速发展的今天，线上教学相对于传统教学的优势显然也在逐步显现出来。相比于传统的教学模式，线上教学在人工和时间上花费的成本很明显要比传统的教学模式更低。因此，线上点名系统的需求就日益增长，由此可见，我们开发的上课点名签到系统的前景可谓十分广阔。上课点名签到系统当前运用的范围也十分广泛，随着国家教育事业的发展，国内中小学进行大规模的扩招，学校对于日常行政管理的信息化需求会日渐增加。而且市面上目前也已经有相当多成熟的软件了，例如：钉钉，学习通，蓝墨云班课等等……我们的项目就是模仿目前市面上已经成熟的管理软件来进行设计。
在可行性方面我们也进行了初步的调研和分析，从而提出了可行性方案并进行研究论证，我在这主要从几个角度来进行分析，分别是使用方面的可行性与经济方面的可行性来进行论证。
使用方面的可行性这点我想应该毋庸置疑，本系统操作十分简单，只需要稍微熟悉一些固定的流程，哪怕没有经过系统训练的人同样能够熟练的运用此系统。
经济方面的可行性，由于本系统是为了提供给相对落后地区的初高中使用而设计的，安装该系统之后立马就可以开始使用此程序，当系统投入运行之后，可以节省大量的财力和人力进行管理。只需要前期投入少量人力进行软件开发即可。因此可以说是十分经济实惠的系统了。
4.硬数据采样
本项目的业务数据资料主要来源是通过惠州学院各院系各年级班长班级考勤资料得出，并通过采访询问他们在日常考勤管理活动中的需求。根据以上资料对项目进行设计和完善。
根据采访内容，我们小组得出，70%的班长对于管理上课考勤情况十分头疼，他们目前管理考勤的方法基本都是靠传统的纸质文档进行管理，因此当出现需要调查某个同学的考勤情况的时候，就会十分困难。并且同学没有签到的原因也可能各不相同：1、一整节课都没有到教室进行上课，也就是俗称的旷课。2、并不是没有参加上课的教学活动。只是因为某些各种各样的原因而导致迟到没有赶上签到。这种要算作迟到而不是旷课。3、既不是旷课，也不是迟到，而是因为自身的某些原因导致要请假。有可能是有事而在上课前几天就提前请好的事假，也可能是当前上课前夕突然感到身体不舒服而临时请的病假。由于学校管理制度的问题。请假所需要的请假条并不能很快的进行批准，因此，虽然这节课上这位同学没有签到而被系统登记到的是旷课。但实际上的情况这位同学应该被登记为的情况应该是请假。这些都是系统所需要考虑到的问题。
5. 用户需求
根据我们的调查，几乎所有班级在学期末都会进行一次考勤考察。如果按照传统纸质文档管理的情况，那无疑是一项十分繁琐的工作，因此，我们的系统需要实现一个判断学生未签到情况的功能，并且在学期末时能够进行一个汇总。并将数据输出出来便于管理。管理员可在本系统中对学校内部人员进行资源管理，信息管理等操作。学生和教师可在本系统中修改个人信息和查看他人基本信息。
Requirements Traceability Diagram
适用环境：有一个需求层次结构，以及来自许多其他元素的跟踪，包括:涉众、块和测试用例。
使用目的：允许系统工程师创建一个图，其中模型元素和它们相关的需求之间的关系可以可视化，包括其他需求。
绘制步骤：创建了一些元素和一个图表，这些元素和图表将目标的实现建模为需求和约束，以及这些需求是如何通过业务和等核心元素实现的应用程序服务。引入颜色是为了增加图表的吸引力，并区分元素类型。
图例说明：创建元素和一个显示它们之间关系的追溯关系图需求和模型中的其他元素，包括拥有需求块、用例和测试的涉众情况下。
- 项目需求分析规格书
Requirement Specification View
适用环境：实现更加完善的需求分析。
使用目的：系统描述了需求规格，使需求更加透明和易理解。
绘制步骤：收集客户意见，与开发人员思想进行联系，进行具体分析。
图例说明：使需求分析具体化，透明化，让开发人员更加容易与客户想法想联系起来。
(1)编写目的
编写此需求说明书是为了使用户和开发人员对所开发的系统有一致的理解。通过阅读此文档,开发人员可以了解当前业务的具体需求和要实现的主要功能,用户通过阅读此文档可以确认开发人员对其业务需求的认识是否正确,并对系统要实现功能有初步的了解。
(2)定义
应对教师和学生入学和退学,上课考勤管理易出错,，学生签到管理系统提供完整的学生和教师情况的具体完成表。
(3)参考资料
[1]《需求分析 软件需求与建模 第2版》骆斌 丁二玉著 2015.2
2.项目概述
(1)项目前景
学生签到管理系统主要用于管理学生和教师对于签到的发布，签到的完成情况还有签到时间的约束。管理员主要对于教师和学生个人资料进行增删改查。
目标客户：学校管理员
优势：高效便捷，在学校的日常管理中，平时考勤和学生签到情况是一件由为复杂的情况，加上一起学生在家上网学习和现在管理越来越复杂的环境下，学生点名签到系统的出现尤其重要，这一方面，这个系统减少了学生管理的压力，加快了管理的速度，另一方面，这是促进科技发展和符合信息科学发展的科学发展理念。
Business Motivation Model
适用环境：具体描述该系统的商业动机和该系统未来应有怎么样的市场。
使用目的：系统描述了项目的商业动机性，实现未来市场规划。
绘制步骤：收集市场中各类相似APP的市场需求和规划，结合该系统的市场定位。
图例说明：让开发人员更加明确该系统的市场定位和未来该项目的市场需求。
(2)目标
适用到个学校的学生和教师发布签到管理
在第一阶段实现高效学生签到管理基础功能，管理员以管理员权限登录系统，录入教师信息，管理增添、修改、删减员工信息，学生以用户权限登录系统，查看学生个人资料方式已经查看自身信息和修改自身信息。
第二阶段实现教师的发布签到和学生完成签到的情况
第三阶段实现学生完成签到情况统计
最后阶段测试系统，实现所有功能。
Capability Roadmap
适用环境：通常情况下，当业务中发生重大变化时，需要计划和开发对业务需求至关重要的核心或额外功能，并且在图表上的时间尺度所涵盖的时间段内，这也将是有用的参考。
使用目的：允许业务架构师、业务分析人员或其他涉众创建或查看组织计划在指定时间框架内创建或获取的功能的高层概要。
绘制步骤：使用泳道显示功能路线图图，以指示路线图的每个方面中的项目。图例控制指示相位的彩色带。
图例说明：创建了一些元素和路线图图，这些元素和路线图图关注于一个组织已经计划的能力，并详细说明了何时开发或获取这些能力的时间表。路线图被分为许多有助于功能可视化的部分。
(3)应用用户
一、疫情期间的学校或者小型刚起步要扩展的学校。
二、满足1条件，且需要扩展开展更多班级的学校
三、需要特定功能的用户管理系统
对于这些该起步的小型学校来说，市面上提供的信息管理系统虽然涵盖了大部分的学生签到管理的大部分功能，但定价高昂。本系统适用于这些对象。本系统可作为从疫情开始到结束的一个好的过度。
Project Roadmap
适用环境：通常用于确保对重要里程碑、可交付成果和组件有一个概述，以便在激烈的分析和实现过程中存在一个清晰而简单的计划，在高层次上描述项目。
使用目的：允许首席信息官、架构师、分析师和其他高级涉众获取项目的重要和高级方面的基于时间的可视化。
绘制步骤：使用泳道显示项目路线图图中每个方面的项。图例控制指示相位的彩色带。
图例说明：创建了一些元素和路线图图，这些元素和路线图图关注于项目的目标、目标、里程碑和可交付成果。它创建kev里程碑、计划和组成解决方案的高级组件的高级视图。路线图被分为许多部分，这些部分有助于可视化产品的特性、技术能力和一致性。
3.业务需求分析
(1)系统范围
主要的功能分布在三个UI（User Interface）——管理员UI和教师UI和学生UI
学校管理员管理教师和学生——即管理员以管理员权限登录系统，并在此系统中完成各项管理事务。
管理员录入初始信息，包括职务名称、教师的资料。
当教师职位变动时，由管理员管修改相关信息，并重新生成基本教师个人信息。
教师和学生可以用户的权限登录该系统，查询和修改自己的员工资料，并切教师可以发布签到消息，学生可以完成签到消息。
Composite Requirement Hierarchy
适用环境：当系统工程师需要显示需求层次结构的单个级别，但又想表明这些需求是由其他需求组成的，允许向下钻到其他级别时。
使用目的：提供一种可视化需求集合的结构的方法，通过在元素右下角的标记指出一个或多个需求具有子元素。复合模式可以应用到任何级别。
绘制步骤：收集市场中各类相似APP的组织结构对比参照并联合客户需求进行修改。
图例说明：一个显示子需求的需求图，其中一个有一个复合标记，指示它可以被双击来显示层次结构中的下一个层次。
(2)系统功能模组
管理员UI
人事管理：人事档案管理、考勤管理、考核管理、调动管理、职称评定、奖惩管理和人事统计。
工资管理：职务设定、基本工资设定、工资表生成、工资表查询、工资奖惩、月末工资处理。
综合管理：部门管理、假期与出差管理、员工聘用合同与通知。
系统管理：数据备份与还原、系统初始化。
用户管理：用户管理、权限设置。
用户UI
用户管理：自身档案管理、考勤管理、考核管理、调动管理、职称评定、奖惩管理和人事统计。
工资查看：职务设定、基本工资设定、工资表生成、工资表查询、工资奖惩、月末工资处理。
综合管理：部门管理、假期与出差管理、员工聘用合同与通知。
(3)系统分析
通过用户的业务需求，在活动中分析其动机视图：
Motivation Viewpoint
适用环境：该模式通常在计划的分析阶段使用，以获得对需求和约束如何与涉众和其他定义其目标的事物联系起来的概述和洞察。
使用目的：提供一个关于计划的动机方面的丰富视图，显示从高级别涉众到需求的分解。它为企业、业务和技术架构师、业务分析师、需求经理和其他关注架构战略、战术和动机的涉众提供了一个视图。
绘制步骤：从一个给定的利益相关者的角度来完全覆盖动机方面，定义了驱动因素、评估、一些目标和应用的原则，以及限定原则所需的要求和约束。
图例说明：显示一个动机图，包含涉众的分解，以及定义他们的目标到指定系统必须展示的行为的需求的元素。
(4)系统总体流程
在动机视图的基础上，建立系列功能流程图，系统的主要流程图如下：
Sequence Diagram
适用环境：表达功能流程。
使用目的：描述了在一个用例或操作的执行过程中对象如何通过消息相互交互，说明了消息如何在对象之间被发送和接收以及发送的顺序，通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协。
绘制步骤：
1.划清边界，识别交互语境
所谓划清边界是是指要确定好绘制时序图的范围。
所谓识别交互语境就是要知道自己绘制时序图的前提和背景。
2.梳理时序图中的角色和对象都有哪些
3.对象之间有哪些交互消息
图例说明：这是我们系统的功能流程时序图，员工输入登录系统并是否返回，管理员管理数据库对用户进行管理；教师发布签到消息给学生，学生完成签到情况，然后消息回显给教师。
(5)具体业务需求分析
学生签到管理系统主要用于管理学生和教师对于签到的发布，签到的完成情况还有签到时间的约束。管理员主要对于教师和学生个人资料进行增删改查。
业务功能：
管理员可在本系统中对教师和学生信息管理等操作。
教师和学生可在本系统中修改个人信息和查看他人基本信息。
Requirements Realization Viewpoint
适用环境：该模式通常在定义了目标、明确了需求和约束、设计了业务服务、流程和应用程序服务及组件的分析阶段使用。它也可以在应用程序或流程重新评估阶段使用。
使用目的：允许企业、业务和技术架构师、业务分析人员、需求管理人员对表示服务的元素和实现这些服务的元素分解和实现需求的方式进行建模和可视化。
绘制步骤：创建了一些元素和一个图表，这些元素和图表将目标的实现建模为需求和约束，以及这些需求是如何通过业务和等核心元素实现的应用程序服务。引入颜色是为了增加图表的吸引力，并区分元素类型。
图例说明：显示目标、需求和业务和应用程序服务的核心元素之间的关系。
4.非功能性需求
(1)性能需求
[1]精度
保证查找的完整性，对学生的查找方式进行了模糊查询的方式，在查找的时候输入学生的资料可以查询到学生的个人完成情况。
在网络延迟或者设备出现意外的情况下可以和教师反馈，最终教师在签到情况表进行学生签到情况的修改
[2]时间特性要求
在一般情况下响应时间都不会很长，使用Ajax技术帮助了我们实现数据的立即性反馈。在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。
Domain Model Diagram
适用环境：数据库表单联系。
使用目的：对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系管理和提供信息。
绘制步骤：对信息进行精准分析，根据数据流输入和输出，关联起来。
图例说明：这是我们系统的Domain Model Diagram，描述了我们系统的对象之间的关系，建立联系，添加索引，加快查询，提高系统反应时间。
[3]灵活性
系统采用类似于网站的操作界面,以视窗操作系统为基础,可通过foxpro或access等数据库引擎与其它系统交换数据。符合证书管理及制作的规范要求,能够满足日常的工作需要。
(2)发布签到和完成签到要求
在这个系统里面，我们通常根据教师的签到表来完成签到，于此同时，教师需要在合理规定的时间内发布签到，学生也需要在教师限定的时间内完成签到
(3)故障处理要求
数据库引擎出现故障可能导致整个系统的瘫痪,影响所有的操作人员,建议配置一个后备服务器应急。
网络连接故障会导致无法连入数据库,从而使某个操作人员无法使用系统,需人工排查网络故障。系统需用到一些外部辅助软件,例如office 等,如果未安装这些软件,可能会影响部分功能,比如无法生成word, excel文档,无法导出access 数据格式等。
(4)其他专门要求
教师和学生对安全保密的要求,对使用方便的要求,对可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
Non Functional Requirements Diagram
适用环境：实现更加完善的系统项目。
使用目的：系统描述了非功能需求。
绘制步骤：进行非功能需求分析，获取非功能需求
- 依赖功能需求识别、获取非功能需求目标。
- 根据非功能需求层次结构，精华非功能需求目标。
- 量化底层非功能需求目标的验收标准。
图例说明：罗列出系统项目的非功能需求，避免系统实现时，发生系统故障，甚至实现项目失败的案例。
(1)数据流
通过活动图和时序图，理解业务的过程，知道活动与活动之间的联系，对象与对象的交互，在这些目标之间的交互中，会有数据之间的交流，数据的输入和输出，数据从另一个对象到另一个对象。系统的数据流图如下：
Data Flow Model pattern
适用环境：清晰表达对数据的处理。
使用目的：用于分析和信息系统投影。数据流图用于以图形方式表示信息系统中的数据流，并用于分析结构投影过程中的数据处理。
绘制步骤：通过功能流程时序图的流程，在此基础上了解流程中的数据流动，并对这些数据进行输入输出完成数据流。
图例说明：该图显示管理系统、请假系统、管理系统与用户之间的交互以及请假系统与用户之间的交互。
(2)数据库与数据表单
MySQL and Database
适用环境：建立数据库，通常用于项目或迭代的分析、设计或测试阶段，当数据库工程师或信息架构师需要为应用程序、子系统或平台定义数据层时。它可以在产品开发的整个生命周期中使用，并支持对模型和实时数据库的差异分析，以及模型和数据库的同步。
使用目的：让数据库工程师、数据库管理员和所有者拥有一个基本模型，该模型将作为数据库模型的起点，包括概念、逻辑和物理数据模型以及表、视图和其他数据库对象的定义。它提供了一个项目浏览器结构，对于组织数据模型非常有用，根据实际业务需求抽象出实体、实体的属性和实体的联系，抽象业务所涉及的E-R图，能够优化E-R图并形成用于数据库系统逻辑设计的全局E-R图。
绘制步骤：显示了使用信息工程表示法通过外键关系连接的三个表，通过对数据流还有domain domel的建立，对数据表进行属性确定，构建完善的数据库。
图例说明：基本的MySQL模型模式为数据库建模创建元素和图表，包括概念、逻辑和物理数据模型。它提供了一个基本的模型和包结构，以及许多预定义的模型和元素，包括提供起点的数据库对象，如表和视图。然后，可以使用物理数据模型生成DDL, DDL可以使用到一个或多个活动数据库的已定义连接来执行。
(3)数据原则
Principles Viewpoint
适用环境：展示了一个与原则和他们实现的目标相关的动机图。元素上运用了色彩，使图表更有吸引力。
使用目的：允许企业和信息技术架构师以及其他涉众将原则与目标联系起来。这些原则将形成需求表达的基础。
绘制步骤：创建了一些元素和一个对目标和原则之间的关系进行建模的图表。聚合关系建模目标的分解和实现关系建模原则如何与一个或多个目标相关联。
图例说明：该模式通常在活动的早期阶段使用，并通常构成企业体系结构的一部分，由许多活动重用。
6.运行环境规定
(1)硬件配置
[1]客户端系统要求
Windows 10
(2)软件配置
[1]客户端系统要求
Windows 10
[2]服务器系统要求
平台: MySQL Server 8.0.22
服务器数据库: Oracle 9i Server
Deploy Diagram
适用环境：表示如何通过实体实现组件，也可以表示实体的内部结构。
使用目的：显示系统的逻辑或物理网络架构，描述规范级别的架构，也可以描述实例级别的架构。
绘制步骤：根据自己系统项目需要做成app类型还时网页类型，做出决定后，对系统进行构架。
图例说明：Web应用到Web服务器以及部署数据库mysql到数据库系统部署的样图；以及应用到应用服务器以及部署若干mysql到数据库服务器的样图。
四.需求分析应有需求测试与改善计划
(1)概述
[1]目的
- 把用户需求转变为功能需求
- 对测试范围进行度量
- 对处理分支进行度量
- 对需要的业务场景可以度量
- 明确其功能点对应的输出、处理和输出
- 把隐式需求转为明确
[2]依据
- GB/T16260. 1-2006《软件工程产品质量第1部分:质量模型》
- 软件系统相关的协议、规范
[3]方法
- 列出软件开发需求中具有可测试性的开发需求
- 建立测试需求跟踪矩阵，对需求进行管理
(2)需求测试分析
[1]原始需求
原始需求是从用户需求、产品包需求、系统需求、测试经验库、协议规范等需求来源中提取的经过整理的输入集合。本文的原始需求亦即经过整理成文的业务需求，将每一条需求对应的系统、业务需求编号、业务需求说明及相关文档注明。其中系统名称为被测系统名称；需求版本号为业务需求版本号；业务需求的编号和业务需求名称引用需求分析文档编号及名称,描述引用需求分析文档描述。
业务需求表
| 系统名称 | 需求版本 | 业务需求编号 | 业务需求名 | 业务需求描述 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[2]产品需求测试列表
需求测试列表是在原始需求列表的基础上，对每一条原始业务需求进行分析，形成可测试的分层描述的测试要点，再根据标准和需求文档对每一个测试要点进行分析，得出需要执行的测试类型和更详细的测试描述，最终与原始需求列表综合形成需求测试列表。
测试需求的类型，可分为功能性、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复时间测试、配置测试、兼容性测试、可维护性测试等；前置条件即测试需求需执行的前提条件；优先级一般定义为核心级，重要级，一般级和建议级，其中核心是指针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求；重要是指针对于关键的功能需求、重要的非功能需求及重要的业务流程的测试需求；一般是指对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响；建议是指针对于一般的测试需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的验证，则这些系统功能的需求测试被定义为建议的。
测试需求评审状态包括：未评审、已评审、不评审。
评审的内容包括：
- 完整性评审：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
- 准确性评审：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据；
评审的形式有相互评审、交叉评审；轮查；走查；小组评审；审查。
评审人员：必须存在多种角色，保证不同类型的人员都参与，包括开发经理、项目经理、测试经理、系统分析人员、相关测试人员和开发人员。
根据系统需求，产品有不同类型的测试需求，如功能测试需求、性能测试等，以续表形式分别列出。
[3]功能需求测试
功能测试需求要求描述产品如何响应正确的、可预知的出错条件、非法输入或动作，必须唯一地标示每一个需求。
[4]性能需求测试
性能需求测试要求包括测试精度、时间特性、适应性等要求。
[5]压力需求测试
对系统不断施加压力，通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。
[6]用户界面需求测试
用户界面测试包括可视性(如界面整体布局协调性、色彩搭配合理性、界面要素美观性)、可用性(显控协调性、操作方便性与灵活性、提示、信息反馈、系统响应时间、易学习型、帮助功能完备性和准确性)、健壮性(输入类型及边界控制性能、危险操作拦截提示性能、操作可恢复性)容错等方面。
[7]接口测试
硬件接口：描述系统中软件和硬件每-接口的特征。这种描述可能包括支持的硬件类型和软硬件之间交流的数据、控制信息的性质--级所使用的通信协议。软件接口：描述该产品与其他外部组件的连接，包括数据库、操作系统、工具、库和集成的商业组件，并描述在软件组件之间交换数据或消息的目的、所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。
通信接口：描述与产品所使用的通信功能相关的需求，包括电子邮件、web浏览器、网络通信标准或协议及电子表格，定义了相关的消息格式，规定通信安全或加密问题，数据传输速率和同步通信机制，例如描述计算机与机器硬件接口，波特率等的测试；通信过程中断电的测试，人为中断通信的测试，连续多次通信的测试，通信过程中随意操作按钮的测试。
[8]测试类型确定
根据原始需求及后续分析得到的测试需求列表，确定系统需要的测试类型，在需要测试的项目使用“✓”标注。
表2 待测系统的测试大项
| 系统名称 | 功能测试 | 性能测试 | 可靠性 | 易用性 | 安全性 | 可移植性 | 备注 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(2)测试类型评估
不同测试类型能否发现不同类型的缺陷,依据测试类型来评估测试分析设计工作是非常必要的，必须在产品初期就要规划测试类型，以期尽可能的发现所有相关类型的缺陷。
一个好的系统是可以满足用户的所有需求的，在用户的使用过程中，我们需要提高用户的体验感，完成该系统的整体性。
五.项目Glossary
| 1 | abstraction（抽象） | The essential characteristics of an entity that distinguish it from all other kinds of entities. An abstraction defines a boundary relative to the perspective of the viewer. |
| 2 | asynchronous action（异步动作） | A request where the sending object does not pause to wait for results. Contrast: synchronous action. |
| 3 | boolean expression（布尔表达式） | An expression that evaluates to a boolean value. |
| 4 | Action sequence(操作顺序) | An expression that resolves to a sequence of actions |
| 5 | collaboration（协同） | The specification of how an operation or classifier, such as a use case, is realized by a set of classifiers and associations playing specific roles used in a specific way. The collaboration defines an interaction. See: interaction. |
| 6 | collaboration diagram（合作图） | A diagram that shows interactions organized around the structure of a model, using either classifiers and associations or instances and links. Unlike a sequence diagram, a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: sequence diagram. |
| 7 | component diagram（构建图） | A diagram that shows the organizations and dependencies among components. |
| 8 | concrete class（实体类） | A class that can be directly instantiated. Contrast: abstract class. |
| 9 | Sequence diagram（时序图） | A diagram type in UML which models the interactions between a selected set of objects and/or actors in the sequential order that those interactions occur. |
| 10 | Steering committee(指导委员会) | A committee that supervises a project |
| 11 | object lifeline (对象生命线) | A line in a sequence diagram that represents the existence |
| 12 | collaboration diagram（协作图） | A diagram that shows interactions organized around the |
| 13 | pseudo-state（伪状态） | A vertex in a state machine that has the form of a state, but |
| 14 | acceptance(验收承认) | immediate acceptance,general acceptance,universal |
| 15 | Model Elaboration（模型精化） | The process of generating a repository type from a published model. Includes the generation of interfaces and implementations which allows repositories to be instantiated and populated based on, and in compliance with, the model elaborated. |
| 16 | interaction diagram（交互图） | A generic term that applies to several types of diagrams that |
| 17 | use case diagram（用例图） | A diagram that shows the relationships among actors and |
| 18 | analysis time(验收时间） | Refers to something that occurs during an analysis phase of the software development process. See: design time, |
| 19 | Component（组件） | A physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files. |
| 20 | use case model（用例模型） | A model that describes a system’s functional requirements |
| 21 | distribution unit | A set of objects or components that are allocated to a process or a processor as a group. A distribution unit can be represented by a run-time composite or an aggregate. |
| 22 | meta-metamodel | A model that defines the language for expressing a metamodel.The relationship between a meta-metamodeland a metamodel is analogous to the relationship between ametamodel and a model. |
| 23 | association end | The endpoint of an association, which connects the association to a classifier |
| 24 | multiple inheritance | A semantic variation of generalization in which a type may have more than one supertype. Contrast: single inheritance. |
| 25 | state machine 状态机 | State machine diagram is a UML diagram used to model the dynamic nature of a system. |
| 26 | parameterized element 参数化元素 | The descriptor for a class with one or more unbound parameters |
| 27 | containment hierarchy 包含层次结构 | A namespace hierarchy consisting of model elements.andthe containment relationships that exist between them. Acontainment hierarchy forms an acyclic graph. |
| 28 | active object 活动对象 | Active Objects is a new ORM (object relational mapping) layer into Atlassian products. Active Objects is implemented as a plugin into Atlassian applications. |
| 29 | 数据流图（Dataflow diagram） | A coarse description of the required capabilities of a system from the customer's perspective. |
| 30 | dynamic classification | A semantic variation of generalization in which an objectmay change type or role. Contrast: siatic classification. |
标签：需求,管理,签到,G003,09,系统,学生,测试,185 来源： https://blog.csdn.net/weixin_43312807/article/details/111963196