需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。

一、主要内容

总体上说，需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。具体分为功能性需求、非功能性需求与设计约束三个方面。

1．功能性需求

功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。

2．非功能性需求

作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。

3．设计约束

一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。

具体而言，本例实验包括系统的总体需求分析和软件需求分析，内容详见实验步骤。

二、实现平台

系统平台：略

三、具体内容

系统的总体需求分析：

1、获取用户需求

系统主要角色：系统管理员、学生、教师

管理员：能够对本账号的个人资料进行查阅并修改，在拥有对学生、教师等的用户账号密码进行重置等权限的基础上，对普通用户账号信息拥有超级权限；同时，能够进行后勤厂商设备管理、以及在不同用户账号之间进行信息交流；等等。

学生：除了能够自身的账号信息进行修改外，能在账号通信的前提之下，进行来自上层权限账号的通信接收；以校园生活主题为维度，学生拥有注销、设备使用、查阅课程表等的功能需求；等等。

教师：仅作为一个校园生活为主流的教师账号而言，除却能对自身的信息进行维护之外，通常都将拥有学生的成绩录入、课程信息的相关通知；教师也将拥有来自学生角色的部分功能，如校园设备使用、接收来自上层权限账号的通信；等等。

2、确定功能需求

1）、基本信息维护：

对于全局角色而言，学生、教师以及系统管理员在完成登录之后，可以自选式进行个人信息的基本维护，如出生年月、性别和账号密码之类的修改；而对于系统管理员而言，能够拥有学生和教师账号密码重置的超级权限，以防止并解决用户在使用账号过程中发生密码遗忘的问题；等等。

2）、通知推广以及信息接收：

在设计之初，以学生权限继承于教师，而教师权限继承系统管理员的思想维度考虑，系统管理员可以对学生和教师账号进行通信信息推广，而学生和教师角色仅能对此进行回应。如果要逆权限进行数据对话，必须通过用户反馈功能模块。

3）、设备使用和维护：

校园后勤所涉及的使用设备，均来自校方的企业合作，因此能够对设备进行维护的，也仅由校方的工作人员，即系统管理员。而设备的使用权，对于各账号均有效。

4）、教学场所的借阅和维护：

教学场所的统一管理标准完全是以教务处制定，因此校方的系统管理员和对教师的教室申请能够进行审批等权限，这得在教师主动申请补课或者系统管理员统一排课的前提之下。

5）、学生管理：

学生可以通过登录，查看自己的各种使用余额，并可以通过网上支付的方式快速充值，无须排队。

6）、教师管理：

每个教师须注册自己的账号，通过账号可实时查询自己书籍借阅。与其他的使用情况。

7）、机构管理：

管理员可将学生信息录入学生表，也可以批量导入学生信息，并可指定搜索学生，查看并修改其信息。

8）、机器管理：

每台连接上此系统的机器，都要与管理数据库链接，并定时发送信息，确保机器稳定运行，并能通过此信息快速定位损坏机器，方便维修。

3、分析性能需求

1）、正确性需求：

在精度需求上，根据实际需要，数据在输入、输出及传输的过程中要满足各种精度的需求根据关键字精度的不同。如：查找可分为精确查找和泛型查找，精确查找可精确匹配与输入完全一致的查询结果，泛型查找，只要满足与输入的关键字相匹配的输入即输出，可供查找。

2）、安全性需求：

只有合法用户才能登录使用系统，对每个用户都有权限设置。对登录名、密码、以及用户重要信息进行加密，保证账号信息安全。

3）、并发能力：　系统同时处理的request／事务数

4）、处理时间：

系统响应时间应在人的感觉和视觉范围内(<1 s)，系统响应时间足够迅速(<5 s)，能够满足用户要求。

5）、响应速度：ＱＰＳ（ＴＰＳ）＝　并发数／平均响应时间

6）、数据恢复：

系统采用了记录日志，用于记录用户的操作及故障信息，同时本系统采用的B/S模式，结构清晰，便于维护人员进行维护.

4、其他一些需求

1）、开发性：

①.有良好的开发流程和环境

②.有各个技术人员尽责

③.有先进的技术设备

2）、界面友好：

该系统界面设计美观大方。符合现代人的审美观，页面显示信息清晰明了，操作简单。

3）、一致性：

当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。

4）、弱一致性：

系统并不保证续进程或者线程的访问都会返回最新的更新过的值。在系统返回之前需要满足一定的条件，更新操作完成之后到访问返回最新值之间的时间窗口称为不一致窗口。

5）、最终一致性：

弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS是一个典型的最终一致性系统。

 

软件需求分析：

1．确定总体目标及组织结构

在对校园生活一体化管理系统进行调研和分析的基础上,可以画出新系统的组织结构图，并列出各部门的岗位角色表，如图3-1和表3-1所示。

图3-1 图书馆组织结构图（略）

表3-1岗位角色

2．深入领域分析，画出业务流程图（略）

3．分析数据流程，画出数据流图（略）

4．确定功能需求，完成功能结构图及点列表

校园生活一体化管理系统的部分性能点列表(性能模型)，如表3-2所示。

表3-2 校园生活一体化管理系统的性能点列表

6．明确处理关系，列出接口列表

校园生活一体化管理系统的部分接口列表，如表3-3 目标系统的接口列表(接口模型)

（略）

   3.3.2 业务流程图

企业投资项目审批过程业务流程图，如图3-4所示。

3.3.3 数据流图及数据字典

表3-7 数据流定义

校园生活一体化管理系统的DFD图，如图3-7所示。对于校园生活一体化管理系统，需要接收来自用户的登录信息，并验证，验证过程主要根据用户权限的正确性，并由用户档案确定是否登录成功情况。

图3-7  系统的DFD图

四、需求分析结果

经过开发的研讨，加之参与体系化的深入分析，本例满足目前市场所流行的功能使用性。由此，校园生活一体化管理系统可进入下一阶段的研发。

五、需求经验

经过研发小组初步促成共识，本例实验心得可总结如下：

(1)应用领域的复杂性及业务变化，难以具体确定，同时，用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等；

(2)软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性；

(3)需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难；

(4)获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义；

(5)需求难以进行深入的分析与完善。需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施；等等。