G003-186-18

计算机科学与工程学院

小组期末报告
2020～2021 学年第 1 学期

课程 软件需求分析与建模
课程项目名称 调查问卷系统
团队成员 罗远彬 李尚豪
学号 1814080902611、1814080902622
专业班级 18软件工程6班
指导教师 董瑞生
提交时间 2020年12月27日

目录
一． 项目需求提案计划书 3
1.引言 3
1.1原因 3
1.2背景 3
1.3意义 4
1.4参考资料 4
2. 项目概述 4
2.1项目范畴 4
2.2项目简介及目标 4
二． 项目需求萃取分析书 4

1. 引言 4
   1.1目的 4
   1.2项目前景与范围 4
   1.3参考文献 5
   2.问题分析 5
   2.1问题域 5
   2.2获取问题 5
   2.3明确问题 5
   2.4业务需求 5
   2.5解决方案 5
   2.6业务过程分析 7
   3.涉众分析 7
   3.1涉众 7
   3.2硬数据即硬数据采样 9
   4.场景模型分析 11
   4.1系统环境 11
   4.2展开用户需求获取 11
   4.3用户需求 12
   三． 项目需求分析规格书 12
2. 引言 13
   1.1编写目的 13
   1.2定义 13
   1.3参考资料 13
   2.项目概述 13
   2.1项目前景 13
   2.2目标 14
   2.3应用用户 15
   3.业务需求分析 16
   3.1系统范围 16
   3.2系统功能模组 17
   3.3系统分析 17
   3.4系统总体流程 18
   3.5具体业务需求分析 19
   4.非功能性需求 19
   4.1性能需求 19
   4.2输入输出要求 20
   4.3故障处理要求 20
   4.4其他专门要求 21
3. 数据分析 21
   5.1数据流 21
   5.2数据库与数据表单 22
   5.3数据原则 23
   6.运行环境规定 24
   6.1硬件配置 24
   6.2软件配置 24
   四． 需求分析应有需求测试与改善计划 25
4. 需求测试 25
   1.1概述 25
   1.2需求测试分析 25
   1.3测试类型评估 27
5. 改善计划 27
   五． 项目Glossary 28

一．项目需求提案计划书
1.引言
1.1原因
信息调研的对象是广大的人群，这些信息是在变化的。但是用户想要快速准确的掌握实时数据。由于人员众多、数据源复杂、统计管理工作闲难，以往每做一项工作，都需要花费很多的精力和时间。传统的人工使用纸质调查问卷的方式存有诸如效率低，保密性差，查找、更新等各种各样的缺点。因此，调查问卷系统能够为用户提供充足的问卷模板和数据更新统计以及发布问卷方式等手段。使用计算机对问卷进行统计，会给应用者带来很多方便，例如检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高调查的效率。
1.2背景
随着科技的飞速发展，计算机已经广泛的应用于各个领域之中，而且日趋普及。在计算机应用中很重要的一部分就是编程语言，它的出现打开了计算机应用的新篇章。选举、调查不再局限于以往的方式，调查问卷系统以更便捷、更快速、更经济、更准确的优势广泛应用于各种网络投票选举、问卷调查中。它将用户和网站很好的联系起来，进而达到互联网资源共享的目的。调查问卷系统可以用来统计网站用户对某个主题或热门话题的意见。网站管理员也可以通过在线投票系统这个媒介去了解用户的思想、意见，并通过在线投票系统的结果反馈改进工作策略
1.3意义
①　大幅度提高工作效率，使用户能够更高效准确的获取到统计数据。
②　用计算机数据库管理代替手工统计工作，并且对数据库中的各数据自动进行逻辑验证，使数据统计过程中的错漏减少到最低程度。
③　使各管理部门的信息管理工作规范化、高效化，大大简化数据汇总的工作量。
1.4参考资料
[1]《需求分析 软件需求与建模 第2版》骆斌 丁二玉著 2015.2
[2] https://wenku.baidu.com/view/7444bb016c85ec3a87c2c584.html#
2.项目概述
2.1项目范畴
由于调查问卷系统功能全面、丰富，流程相对复杂、工作量大，因此，为便于系统开发治理，降低风险，公司将调查问卷系统拆分为两个子系统:
Windows系统，实现问卷发布，模板查询，请调查公司帮助及信息统计分析结果呈现等功能。
SQL系统，要紧实现数据治理功能。其中所涉及的功能要紧是设计数据库中的对象，如表、视图、储备过程等。涉及界面操作的功能Windows子系统实现
2.2项目简介及目标
我们小组项目的主要功能包括登录、发布问卷、结果查看等部分，用户可随意增删和修改投票项目，设定隐藏、公布投票结果，并且可以寻求专业调查公司的帮助，游客的功能则是填写问卷管理员则是后台管理和审核问卷以及响应用户的寻求专业调查公司帮助的请求等功能我们的目标是提供一个在线的信息调研平台。
二．项目需求萃取分析书
1.引言
1.1目的
从人员、资料和环境中得到系统开发所需要的相关信息，对项目进行需求收集。对用户和开发人员的背景不同，立场不同的环境中，解决他们之间的知识理解的困难，开发人员清楚并完整地获取用户的需求，清楚地理解所要解决的问题。到后面找出其的问题域以及要分析的内容。
1.2项目前景与范围
调查问卷管理系统主要用于社会间的问卷调查及收集
目标客户：学生及社区的民众
优势：在数字化飞速发展的今天，网络调研较好地解决了传统调研方法所得的调研结果都存在时效性这一难题。只要轻轻一点，世界任何一个角落的用户都可以加入其中，从用户输入信息到公司接收，只不过几秒钟的时间。利用计算机软件整理资料，马上可以得出调研的结果。而被调查者只要点击“结果”键，就可以知道现在为止所有被调查者的观点所占的比例，使用户了解公司此次的调研活动，加强参与感，提高满意度，实现了信息的全面共享。范围：主要致力与社区内部以及学校内部的小范围性投票.。

1.3参考文献
[1]《需求分析 软件需求与建模 第2版》骆斌 丁二玉著 2015.2
2.问题分析
2.1问题域
用户对系统内部的问卷模板进行查询使用，自己创建问卷进行问题设置以及用户发布问卷，查看统计结果，寻求专业公司帮助等操作
游客填写用户发布的问卷需要先登陆在填写。
管理员审核发布问卷信息及响应用户的寻求帮助的需求
2.2获取问题
P1：实时数据的统计繁杂，效率低下。
P2：问卷审核的数量大，管理员工作量加大效率低。
2.3明确问题

2.4业务需求
此业务需求是跟据网上资料查询，某公司在使用类似系统后的业务需求：
BR1：在系统使用6个月后，问卷调研效率提高50%，问卷在网上可查询
BR2：在系统使用6个月后，数据统计功能，工作效率提高50%。
2.5解决方案

Use Case Model
适用环境：用户、客户对开发人员举例的解决方案不太理解。
使用目的：系统描述了问题解决方案的内容，描述外部角色在与解决方案的交互中完成的任务与目标；同时从系统特性中抽取，找到系统特性中蕴含的外部角色及交互任务。
绘制步骤：通过问题域、涉众上进行获取问题和明确问题，对发现的每个问题进行“明确问题→发现业务需求→定义问题解决方案及系统特性”，得到每个问题的业务需求和解决方案，从而进行绘制用例图。
图例说明：这是问题P1、P2的用例图，在问题P1中，游客和用户外部角色所需要完成的任务是发布问卷，填写问卷及查看结果的统计；在问题P2中，管理员需要完成的任务是审核用户发布的。
2.6业务过程分析
不管是游客还是用户都觉得传统的问卷调查存在较大的问题，如不方便，不快捷，信息存在较大误差等。有略微超过半数的人使用过信息管理类软件，其他人没使用过，且绝大多数人是会尝试信息管理类软件的，说明信息管理类软件有进一步普及的空间。理想中的信息管理软件特点里简洁轻量、易于上手和精准快捷最为用户看重，许多用户也提出了自己期望的功能，其中激励功能、小目标模板期望较多，在开发过程中在有余力的情况下可以考虑实现。

Activity Diagram
适用环境：从活动到活动的控制流。
使用目的：对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。
绘制步骤：根据功能步骤，查看活动，动作完成后通过完成转换转向另一个状态。
图例说明：用户从登录的活动进入到系统，对问卷进行三个活动操作，分别时付费请调查公司帮忙调查、设计发布问卷，查看统计结果。
3.涉众分析
3.1涉众

Organization Chart
适用环境：具体描述该系统包含的部分，使层次结构更加清晰。
使用目的：使层次结构清晰化，开发人员更加容易理解客户需求。
绘制步骤：收集市场中各类相似APP的组织结构对比参照并联合客户需求进行修改。
图例说明：让开发人员更加明确客户的需求和使界面更加整洁。

Organization Viewpoint
适用环境：具体描述该系统前端后端包含的部分和服务的部分，使层次结构更加清晰。
使用目的：使层次结构清晰化，开发人员更加容易理解客户需求。
绘制步骤：收集市场中各类相似APP的组织结构对比参照并联合客户需求进行修改。
图例说明：让开发人员更加明确客户的需求和使界面更加整洁，让开发透明化。
3.2硬数据即硬数据采样
硬数据采样内容：
本项目面谈采用调查问卷形式进行，问卷内容及结果如下

4.场景模型分析
4.1系统环境
随着计算机的发展和互联网时代的带来，我们已经进入了信息时代，也被称为数字时代。在这数字化的时代里，企业的人事需要高效率的管理。信息技术持续迅猛的发展，给传统的人事管理提出更高的要求，随着需求的增加，各相应的产品也逐渐出世。
调查问卷系统就是为了解决信息调研的系统。相似的系统五花八门，各有各的特色。在现在的时代，用于调研的系统有很多。
在此开发的调查问卷系统，旨在适应信息时代，提高调研的效率，帮助用户高效准确的获取数据并保证其数据的安全性去除了传统的纸质调研的繁琐，用户无需经过特殊的训练就可以使用这个系统，降低使用成本，最大程度的满足用户的需求。。
目前市场可提供的信息管理系统虽然涵盖了大部分的调研功能，但是，无法满足特定用户的指定功能。

4.2展开用户需求获取
场景描述：调研的核心职能是通过设置问卷、发布及查看数据来建立一个结构合理的分工协作化组织，来完善问卷调查的过程。
4.3用户需求
管理员可在本系统进行审核问卷等操作。
用户可在本系统中编辑并发布问卷和查看统计结果等操作。
游客可在本系统中填写问卷。

Requirements Traceability Diagram
适用环境：有一个需求层次结构，以及来自许多其他元素的跟踪，包括:涉众、块和测试用例。
使用目的：允许系统工程师创建一个图，其中模型元素和它们相关的需求之间的关系可以可视化，包括其他需求。
绘制步骤：创建了一些元素和一个图表，这些元素和图表将目标的实现建模为需求和约束，以及这些需求是如何通过业务和等核心元素实现的应用程序服务。引入颜色是为了增加图表的吸引力，并区分元素类型。
图例说明：创建元素和一个显示它们之间关系的追溯关系图需求和模型中的其他元素，包括拥有需求块、用例和测试的涉众情况下。
三．项目需求分析规格书

Requirement Specification View
适用环境：实现更加完善的需求分析。
使用目的：系统描述了需求规格，使需求更加透明和易理解。
绘制步骤：收集客户意见，与开发人员思想进行联系，进行具体分析。
图例说明：使需求分析具体化，透明化，让开发人员更加容易与客户想法想联系起来。
1.引言
1.1编写目的
编写此需求说明书是为了使用户和开发人员对所开发的系统有一致的理解。通过阅读此文档,开发人员可以了解当前业务的具体需求和要实现的主要功能,用户通过阅读此文档可以确认开发人员对其业务需求的认识是否正确,并对系统要实现功能有初步的了解。
1.2定义
应对数据统计困难，审核问卷数量多效率低等问题，调查问卷系统提供一站式问卷管理系统高效完成问卷全周期信息化管理。
1.3参考资料
[1]《需求分析 软件需求与建模 第2版》骆斌 丁二玉著 2015.2
[2]《项目需求分析说明书》https://wenku.baidu.com/view/9f863548ef630b1c59eef8c75fbfc77da2699783.html
2.项目概述
2.1项目前景
调查问卷系统主要用于社区学校间的信息调研及统计，管理人员主要用户发布的问卷进行审核。
目标客户：社区居民及在校学生。
优势：在数字化飞速发展的今天，网络调研较好地解决了传统调研方法所得的调研结果都存在时效性这一难题。只要轻轻一点，世界任何一个角落的用户都可以加入其中，从用户输入信息到公司接收，只不过几秒钟的时间。利用计算机软件整理资料，马上可以得出调研的结果。而被调查者只要点击“结果”键，就可以知道现在为止所有被调查者的观点所占的比例，使用户了解公司此次的调研活动，加强参与感，提高满意度，实现了信息的全面共享。

Business Motivation Model
适用环境：具体描述该系统的商业动机和该系统未来应有怎么样的市场。
使用目的：系统描述了项目的商业动机性，实现未来市场规划。
绘制步骤：收集市场中各类相似APP的市场需求和规划，结合该系统的市场定位。
图例说明：让开发人员更加明确该系统的市场定位和未来该项目的市场需求。
2.2目标
适用到各公司内部的业务管理
第一阶段
实现正常普通的公司用户管理系统的基础功能，管理员以管理员权限登录系统，并响应用户请求，用户以用户权限登录系统，发布问卷，付费请求，
第二阶段
管理员审核用户发布的问卷。
游客以游客权限登录系统，填写问卷。
第三阶段
用户查看统计的数据。

Capability Roadmap
适用环境：通常情况下，当业务中发生重大变化时，需要计划和开发对业务需求至关重要的核心或额外功能，并且在图表上的时间尺度所涵盖的时间段内，这也将是有用的参考。
使用目的：允许业务架构师、业务分析人员或其他涉众创建或查看组织计划在指定时间框架内创建或获取的功能的高层概要。
绘制步骤：使用泳道显示功能路线图图，以指示路线图的每个方面中的项目。图例控制指示相位的彩色带。
图例说明：创建了一些元素和路线图图，这些元素和路线图图关注于一个组织已经计划的能力，并详细说明了何时开发或获取这些能力的时间表。路线图被分为许多有助于功能可视化的部分。
2.3应用用户
一．社区居民及工作人员
二．在校学生
对于这些该人来说，调查问卷系统可以给他们提供简便的调研平台，不需要什么培训就可以使用符合他们的需求

Project Roadmap
适用环境：通常用于确保对重要里程碑、可交付成果和组件有一个概述，以便在激烈的分析和实现过程中存在一个清晰而简单的计划，在高层次上描述项目。
使用目的：允许首席信息官、架构师、分析师和其他高级涉众获取项目的重要和高级方面的基于时间的可视化。
绘制步骤：使用泳道显示项目路线图图中每个方面的项。图例控制指示相位的彩色带。
图例说明：创建了一些元素和路线图图，这些元素和路线图图关注于项目的目标、目标、里程碑和可交付成果。它创建kev里程碑、计划和组成解决方案的高级组件的高级视图。路线图被分为许多部分，这些部分有助于可视化产品的特性、技术能力和一致性。
3.业务需求分析
3.1系统范围
主要的功能分布在三个UI（User Interface）——管理员UI和用户UI和游客UI
管理员以管理员权限登录系统，并响应用户请求 
用户以用户的权限登录该系统，发布问卷，付费请求，查看统计数据。
游客以游客的权限登录该系统，填写问卷

Composite Requirement Hierarchy
适用环境：当系统工程师需要显示需求层次结构的单个级别，但又想表明这些需求是由其他需求组成的，允许向下钻到其他级别时。
使用目的：提供一种可视化需求集合的结构的方法，通过在元素右下角的标记指出一个或多个需求具有子元素。复合模式可以应用到任何级别。
绘制步骤：收集市场中各类相似APP的组织结构对比参照并联合客户需求进行修改。
图例说明：一个显示子需求的需求图，其中一个有一个复合标记，指示它可以被双击来显示层次结构中的下一个层次。
3.2系统功能模组
管理员UI
综合管理：问卷审核，问卷模板管理。
系统管理：数据备份与还原、系统初始化。 
用户管理：用户管理、权限设置。
用户UI
综合管理：问卷的发布，数据的查看。
游客UI
综合管理：问卷的填写。
3.3系统分析
活动中分析其动机视图：

Motivation Viewpoint
适用环境：该模式通常在计划的分析阶段使用，以获得对需求和约束如何与涉众和其他定义其目标的事物联系起来的概述和洞察。
使用目的：提供一个关于计划的动机方面的丰富视图，显示从高级别涉众到需求的分解。它为企业、业务和技术架构师、业务分析师、需求经理和其他关注架构战略、战术和动机的涉众提供了一个视图。
绘制步骤：从一个给定的利益相关者的角度来完全覆盖动机方面，定义了驱动因素、评估、一些目标和应用的原则，以及限定原则所需的要求和约束。
图例说明：显示一个动机图，包含涉众的分解，以及定义他们的目标到指定系统必须展示的行为的需求的元素。
3.4系统总体流程
在动机视图的基础上，建立系列功能流程图，系统的主要流程图如下：

Sequence Diagram
适用环境：表达功能流程。
使用目的：描述了在一个用例或操作的执行过程中对象如何通过消息相互交互，说明了消息如何在对象之间被发送和接收以及发送的顺序，通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协。
绘制步骤：
1.划清边界，识别交互语境
所谓划清边界是是指要确定好绘制时序图的范围。
所谓识别交互语境就是要知道自己绘制时序图的前提和背景。
2.梳理时序图中的角色和对象都有哪些
3.对象之间有哪些交互消息
图例说明：这是我们系统的功能流程时序图，用户输入登录系统并是否返回，管理员管理数据库对用户进行管理；用户发布问卷，系统返回信息给管理员，管理员审核通过在通过系统返回信息给用户。
3.5具体业务需求分析
场景描述：调研的核心职能是通过设置问卷、发布及查看数据来建立一个结构合理的分工协作化组织，来完善问卷调查的过程。
。

Requirements Realization Viewpoint
适用环境：该模式通常在定义了目标、明确了需求和约束、设计了业务服务、流程和应用程序服务及组件的分析阶段使用。它也可以在应用程序或流程重新评估阶段使用。
使用目的：允许企业、业务和技术架构师、业务分析人员、需求管理人员对表示服务的元素和实现这些服务的元素分解和实现需求的方式进行建模和可视化。
绘制步骤：创建了一些元素和一个图表，这些元素和图表将目标的实现建模为需求和约束，以及这些需求是如何通过业务和等核心元素实现的应用程序服务。引入颜色是为了增加图表的吸引力，并区分元素类型。
图例说明：显示目标、需求和业务和应用程序服务的核心元素之间的关系。
4.非功能性需求
4.1性能需求
4.1.1精度
保证查全率,所有相应域包含查询关键字的记录都应能查到,因企业用户表中的企业用户信息有可能不全,所以查询时输入的名称尽可能取最关键的部分,采用模糊查询来保证查全率。
保证查准率,查到的记录应与给定的单项或组合查询条件完全匹配。以事务为单位提交数据,若出现异常故障,需返回到未提交前。
4.1.2时间特性要求
在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。
定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。
在网络畅通时，拨号连接GPRS网络所需时间不得超过5秒。
在网络畅通时，电子地图刷新时间不超过10秒。
在推荐配置环境下：登录响应时间在2秒内，刷新栏目响应时间在2秒内，刷新条目分页列表响应时间2秒内，打开信息条目响应时间1秒内，刷新部门、人员列表响应时间2秒内。
在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。

Domain Model Diagram
适用环境：数据库表单联系。
使用目的：对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系管理和提供信息。
绘制步骤：对信息进行精准分析，根据数据流输入和输出，关联起来。
图例说明：这是我们系统的Domain Model Diagram，描述了我们系统的对象之间的关系，建立联系，添加索引，加快查询，提高系统反应时间。
4.1.3灵活性
系统采用类似于网站的操作界面,以视窗操作系统为基础,可通过foxpro或access等数据库引擎与其它系统交换数据。符合证书管理及制作的规范要求,能够满足日常的工作需要。
4.2输入输出要求
输入的数据包括手工录入和批量导入。对精度的要求是金额字段保留小数点后两位。由于外部系统复杂多变,导入导出的数据格式有多种,要求系统能解析绝大部分的数据格式。内部交换数据用XMIL格式。
4.3故障处理要求
数据库引擎出现故障可能导致整个系统的瘫痪,影响所有的操作人员,建议配置一个后备服务器应急。
网络连接故障会导致无法连入数据库,从而使某个操作人员无法使用系统,需人工排查网络故障。系统需用到一些外部辅助软件,例如office 等,如果未安装这些软件,可能会影响部分功能,比如无法生成word, excel文档,无法导出access 数据格式等。
打印机故障会导致无法打印出单据,系统应能在这种情况下,询问并选择其它打印机输出。
4.4其他专门要求
用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

Non Functional Requirements Diagram
适用环境：实现更加完善的系统项目。
使用目的：系统描述了非功能需求。
绘制步骤：进行非功能需求分析，获取非功能需求
（1）依赖功能需求识别、获取非功能需求目标。
（2）根据非功能需求层次结构，精华非功能需求目标。
（3）量化底层非功能需求目标的验收标准。
图例说明：罗列出系统项目的非功能需求，避免系统实现时，发生系统故障，甚至实现项目失败的案例。
5.数据分析
5.1数据流
通过活动图和时序图，理解业务的过程，知道活动与活动之间的联系，对象与对象的交互，在这些目标之间的交互中，会有数据之间的交流，数据的输入和输出，数据从另一个对象到另一个对象。系统的数据流图如下：

Data Flow Model pattern
适用环境：清晰表达对数据的处理。
使用目的：用于分析和信息系统投影。数据流图用于以图形方式表示信息系统中的数据流，并用于分析结构投影过程中的数据处理。
绘制步骤：通过功能流程时序图的流程，在此基础上了解流程中的数据流动，并对这些数据进行输入输出完成数据流。
图例说明：该图显示管理系统、请假系统、管理系统与用户之间的交互以及请假系统与用户之间的交互。
5.2数据库与数据表单

MySQL and Database
适用环境：建立数据库，通常用于项目或迭代的分析、设计或测试阶段，当数据库工程师或信息架构师需要为应用程序、子系统或平台定义数据层时。它可以在产品开发的整个生命周期中使用，并支持对模型和实时数据库的差异分析，以及模型和数据库的同步。
使用目的：让数据库工程师、数据库管理员和所有者拥有一个基本模型，该模型将作为数据库模型的起点，包括概念、逻辑和物理数据模型以及表、视图和其他数据库对象的定义。它提供了一个项目浏览器结构，对于组织数据模型非常有用，根据实际业务需求抽象出实体、实体的属性和实体的联系，抽象业务所涉及的E-R图，能够优化E-R图并形成用于数据库系统逻辑设计的全局E-R图。
绘制步骤：显示了使用信息工程表示法通过外键关系连接的三个表，通过对数据流还有domain domel的建立，对数据表进行属性确定，构建完善的数据库。
图例说明：基本的MySQL模型模式为数据库建模创建元素和图表，包括概念、逻辑和物理数据模型。它提供了一个基本的模型和包结构，以及许多预定义的模型和元素，包括提供起点的数据库对象，如表和视图。然后，可以使用物理数据模型生成DDL, DDL可以使用到一个或多个活动数据库的已定义连接来执行。
5.3数据原则

Principles Viewpoint
适用环境：展示了一个与原则和他们实现的目标相关的动机图。元素上运用了色彩，使图表更有吸引力。
使用目的：允许企业和信息技术架构师以及其他涉众将原则与目标联系起来。这些原则将形成需求表达的基础。
绘制步骤：创建了一些元素和一个对目标和原则之间的关系进行建模的图表。聚合关系建模目标的分解和实现关系建模原则如何与一个或多个目标相关联。
图例说明：该模式通常在活动的早期阶段使用，并通常构成企业体系结构的一部分，由许多活动重用。
6.运行环境规定
6.1硬件配置
6.1.1客户端系统要求
硬件配置: 512M内存, P3 700MHz, 40GB硬盘;
推荐硬件配置: 1GM内存, P4 1.8GHz, 40GB硬盘, 1024x 768分辨率的显示器；
6.1.2服务器系统要求
硬件配置: 2GM内存, Pentium D 2.8GHz, 80GB硬盘;
推荐硬件配置: 2G以上内存,双XEON至强2.8GHz以上CPU, SCSI硬盘;
6.2软件配置
6.2.1客户端系统要求
操作系统: Windows 2000/XP/2003;
浏览器: IE 6.0版本或以上;
6.2.2服务器系统要求
操作系统: Windows 2003 Sever
运行环境: Microsoft Net Frame 2.0GIS
平台: MySQL Server 8.0.22
系统组件: IIS Web
服务器数据库: Oracle 9i Server

Deploy Diagram
适用环境：表示如何通过实体实现组件，也可以表示实体的内部结构。
使用目的：显示系统的逻辑或物理网络架构，描述规范级别的架构，也可以描述实例级别的架构。
绘制步骤：根据自己系统项目需要做成app类型还时网页类型，做出决定后，对系统进行构架。
图例说明：Web应用到Web服务器以及部署数据库mysql到数据库系统部署的样图；以及应用到应用服务器以及部署若干mysql到数据库服务器的样图。
四．需求分析应有需求测试与改善计划
1.需求测试
1.1概述
1.1.1目的
1)把用户需求转变为功能需求
①　对测试范围进行度量
②　对处理分支进行度量
③　对需要的业务场景可以度量
④　明确其功能点对应的输出、处理和输出
2)把隐式需求转为明确
1.1.2依据
1)GB/T16260. 1-2006《软件工程产品质量第1部分:质量模型》
2)GB/T 25000.51-2010《软件工程软件产品质量要求与评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则》
3)软件系统相关的协议、规范
4)待测软件系统业务行标
1.1.3方法
1)列出软件开发需求中具有可测试性的开发需求
2)对1)中的每一条开发需求，形成可测试的分层描述的测试需求
3)对2)形成的测试需求，从GB/T16260. 1-2006 《软件工程产品质量第1部分:质量模型》由定义的软件内部/外部质量模型来确定软件产品的质量需求
4)对3) 所确定的质量要求，分析测试执行时需要实施的测试类型
5)建立测试需求跟踪矩阵，对需求进行管理
1.2需求测试分析
1.2.1原始需求
原始需求是从用户需求、产品包需求、系统需求、测试经验库、协议规范等需求来源中提取的经过整理的输入集合。本文的原始需求亦即经过整理成文的业务需求，将每一条需求对应的系统、业务需求编号、业务需求说明及相关文档注明。其中系统名称为被测系统名称；需求版本号为业务需求版本号；业务需求的编号和业务需求名称引用需求分析文档编号及名称,描述引用需求分析文档描述。

1.2.2产品需求测试列表
需求测试列表是在原始需求列表的基础上，对每一条原始业务需求进行分析，形成可测试的分层描述的测试要点，再根据标准和需求文档对每一个测试要点进行分析，得出需要执行的测试类型和更详细的测试描述，最终与原始需求列表综合形成需求测试列表。
测试需求的类型，可分为功能性、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复时间测试、配置测试、兼容性测试、可维护性测试等；前置条件即测试需求需执行的前提条件；优先级一般定义为核心级，重要级，一般级和建议级，其中核心是指针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求；重要是指针对于关键的功能需求、重要的非功能需求及重要的业务流程的测试需求；一般是指对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响；建议是指针对于一般的测试需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的验证，则这些系统功能的需求测试被定义为建议的。

测试需求评审状态包括：未评审、已评审、不评审。
评审的内容包括：
1)完整性评审：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
2)准确性评审：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据；
评审的形式有相互评审、交叉评审；轮查；走查；小组评审；审查。
评审人员：必须存在多种角色，保证不同类型的人员都参与，包括开发经理、项目经理、测试经理、系统分析人员、相关测试人员和开发人员。
根据系统需求，产品有不同类型的测试需求，如功能测试需求、性能测试等，以续表形式分别列出。
1.2.3功能需求测试
功能测试需求要求描述产品如何响应正确的、可预知的出错条件、非法输入或动作，必须唯一地标示每一个需求。
1.2.4性能需求测试
性能需求测试要求包括测试精度、时间特性、适应性等要求。
1.2.5压力需求测试
对系统不断施加压力，通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。
1.2.6用户界面需求测试
用户界面测试包括可视性(如界面整体布局协调性、色彩搭配合理性、界面要素美观性)、可用性(显控协调性、操作方便性与灵活性、提示、信息反馈、系统响应时间、易学习型、帮助功能完备性和准确性)、健壮性(输入类型及边界控制性能、危险操作拦截提示性能、操作可恢复性)容错等方面。
1.2.7接口测试
硬件接口：描述系统中软件和硬件每-接口的特征。这种描述可能包括支持的硬件类型和软硬件之间交流的数据、控制信息的性质–级所使用的通信协议。软件接口：描述该产品与其他外部组件的连接，包括数据库、操作系统、工具、库和集成的商业组件，并描述在软件组件之间交换数据或消息的目的、所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。
通信接口：描述与产品所使用的通信功能相关的需求，包括电子邮件、web浏览器、网络通信标准或协议及电子表格，定义了相关的消息格式，规定通信安全或加密问题，数据传输速率和同步通信机制，例如描述计算机与机器硬件接口，波特率等的测试；通信过程中断电的测试，人为中断通信的测试，连续多次通信的测试，通信过程中随意操作按钮的测试。
1.2.8测试类型确定
根据原始需求及后续分析得到的测试需求列表，确定系统需要的测试类型，在需要测试的项目使用“✓”标注。

1.3测试类型评估
不同测试类型能否发现不同类型的缺陷,依据测试类型来评估测试分析设计工作是非常必要的，必须在产品初期就要规划测试类型，以期尽可能的发现所有相关类型的缺陷。
2.改善计划
在系统需求不同的情况下，做出了的系统的功能也不同，但拓展的功能有相似的，可以在原来的基础上，加入一些特有的元素。
一款好的企业APP软件必定拥有独特的个性化元素，开发者在为企业app开发定制方案的时候，将企业的结合到应用之中，增强其商业价值。如在为从事蛋糕制作企业定制方案的时候，可以开辟一个供用户自行搭配的平台，用户可以通过自身意愿进行款式选择、颜色搭配、口味设置等进行定制心仪蛋糕，进而有效促进消费。
一切应该开发都是为了迎合用户的喜爱，所以在进行定制开发方案的时候，开发者应该从用户的生活细节出发，挖掘符合产品特点的内容进行广告植入。比如星巴克的Early Bird，从用户的生活细节入手进行开发，其中闹钟的功能符合了用户起床必备，同时结合产品的特点进行设置，用户只需要按时起床就可以从中获得福利，受到了用户的广泛欢迎。
为了增强用户的体验感，很多开发者在开发的过程中，在体验功能中添加了游戏互动的元素。在宜家推出的应用中，用户通过下载该应用就可以按照自己喜爱的模式进行自定义家居布局，并且还可以对自己的创意进行分享，参与到票选的比赛中，增强了用户的参与感。
总之，在自身的核心功能中实现自己的个性化，突出自己的核心功能，从而体现出系统的功能性，我们系统要体先出自己的核心功能时，要具备独特的个性化元素，在相同的系统中体现出自己的价值。

标签：需求,功能,18,G003,系统,用户,186,测试,问卷
来源： https://blog.csdn.net/a4578900/article/details/111998384