需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。
一、主要内容
总体上说，需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。具体分为功能性需求、非功能性需求与设计约束三个方面。
1．功能性需求
功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。
2．非功能性需求
3．设计约束
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。
具体而言，本例实验包括系统的总体需求分析和软件需求分析，内容详见实验步骤。
二、实现平台
系统平台：略
三、具体内容
系统的总体需求分析：
1、获取用户需求
系统主要角色：系统管理员、学生、教师
管理员：能够对本账号的个人资料进行查阅并修改，在拥有对学生、教师等的用户账号密码进行重置等权限的基础上，对普通用户账号信息拥有超级权限；同时，能够进行后勤厂商设备管理、以及在不同用户账号之间进行信息交流；等等。
学生：除了能够自身的账号信息进行修改外，能在账号通信的前提之下，进行来自上层权限账号的通信接收；以校园生活主题为维度，学生拥有注销、设备使用、查阅课程表等的功能需求；等等。
2、确定功能需求
1）、基本信息维护：
2）、通知推广以及信息接收：
在设计之初，以学生权限继承于教师，而教师权限继承系统管理员的思想维度考虑，系统管理员可以对学生和教师账号进行通信信息推广，而学生和教师角色仅能对此进行回应。如果要逆权限进行数据对话，必须通过用户反馈功能模块。
3）、设备使用和维护：
校园后勤所涉及的使用设备，均来自校方的企业合作，因此能够对设备进行维护的，也仅由校方的工作人员，即系统管理员。而设备的使用权，对于各账号均有效。
4）、教学场所的借阅和维护：
教学场所的统一管理标准完全是以教务处制定，因此校方的系统管理员和对教师的教室申请能够进行审批等权限，这得在教师主动申请补课或者系统管理员统一排课的前提之下。
5）、学生管理：
6）、教师管理：
每个教师须注册自己的账号，通过账号可实时查询自己书籍借阅。与其他的使用情况。
7）、机构管理：
管理员可将学生信息录入学生表，也可以批量导入学生信息，并可指定搜索学生，查看并修改其信息。
8）、机器管理：
每台连接上此系统的机器，都要与管理数据库链接，并定时发送信息，确保机器稳定运行，并能通过此信息快速定位损坏机器，方便维修。
3、分析性能需求
1）、正确性需求：
在精度需求上，根据实际需要，数据在输入、输出及传输的过程中要满足各种精度的需求根据关键字精度的不同。如：查找可分为精确查找和泛型查找，精确查找可精确匹配与输入完全一致的查询结果，泛型查找，只要满足与输入的关键字相匹配的输入即输出，可供查找。
2）、安全性需求：
3）、并发能力：系统同时处理的request／事务数
6）、数据恢复：
系统采用了记录日志，用于记录用户的操作及故障信息，同时本系统采用的B/S模式，结构清晰，便于维护人员进行维护.
4、其他一些需求
1）、开发性：
①.有良好的开发流程和环境
②.有各个技术人员尽责
③.有先进的技术设备
2）、界面友好：
该系统界面设计美观大方。符合现代人的审美观，页面显示信息清晰明了，操作简单。
3）、一致性：
当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。
4）、弱一致性：
5）、最终一致性：
软件需求分析：
1．确定总体目标及组织结构
在对校园生活一体化管理系统进行调研和分析的基础上,可以画出新系统的组织结构图，并列出各部门的岗位角色表，如图3-1和表3-1所示。
图3-1图书馆组织结构图（略）
岗位编号
岗位名称
所在部门
岗位职责
1011
教务领导
教务处
进行学生等用户数据进行维护
信息管理和维护
1012
教职工
教务办公室
教授学生
发布通知
1013
社团部门人员
学院下属各社团部
部门成员管理维护
社团内部信息管理和维护
1014
学生
各年级班级
学习、系统的主要使用人员
设备消费者
表3-1岗位角色
2．深入领域分析，画出业务流程图（略）
3．分析数据流程，画出数据流图（略）
4．确定功能需求，完成功能结构图及点列表
校园生活一体化管理系统的部分性能点列表(性能模型)，如表3-2所示。
编号
性能名称
使用部门
使用岗位
性能描述
输入
系统响应
输出
1
教务处、教务办公室
教务领导、
查某在用设备学生<3秒
学生姓名、或学号
按照输入的组合条件，进行模糊查询
显示“学生名字、部门、年级；等等”
2
隶属各年级班级
设备响应操作<2秒
设备编号、社团编号
按照输入的组合条件，进行查询
显示“设备在线情况、账号资金详细周转情况”
3
教务办公室、学院下属各社团部
教职工、社团部门管理人员
所要接受部门编号
表3-2校园生活一体化管理系统的性能点列表
6．明确处理关系，列出接口列表
校园生活一体化管理系统的部分接口列表，如表3-3目标系统的接口列表(接口模型)
（略）
3.3.2业务流程图
企业投资项目审批过程业务流程图，如图3-4所示。
3.3.3数据流图及数据字典
数据元素编号：
ID001
数据元素名称：
学号或职工号
别名：
学生与教职工的标识
简述：
学生与教职工在校的唯一识别代码
类型及宽度：
字符型，11位
取值范围：
“00000000001”～“99999999999”
数据流编号：
D01-01
数据结构名称：
校园一体化管理
学生与教职工的各种充值与借阅书籍的行动
学生与教职工
数据流去向：
图书借阅，水电管理
数据流组成：
学号或职工号+（充值金额+使用时长）
数据流量：
平均100份/小时（仅每学期初）
高峰流量：
500份/小时（上午9:00-11:00）
表3-7数据流定义
图3-7系统的DFD图
四、需求分析结果
经过开发的研讨，加之参与体系化的深入分析，本例满足目前市场所流行的功能使用性。由此，校园生活一体化管理系统可进入下一阶段的研发。
五、需求经验
经过研发小组初步促成共识，本例实验心得可总结如下：
(1)应用领域的复杂性及业务变化，难以具体确定，同时，用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等；
(4)获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义；
(5)需求难以进行深入的分析与完善。需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施；等等。