课程名称 需求分析与建模 班级 18软件工程6班
作业名称 学生宿舍电费管理小组期末报告 教导教师 董瑞生
姓名 吴鸣明、魏兆庆 学号 1814080902628
1814080902613 日期 2020.12.27
目录
一、 项目需求提案计划书 2
1.引言 2
2.项目前景与范围 2
2.项目需求萃取分析书 3
引言： 3
内容概要 3
1.需求获取与分析 4
2.展开用户需求获取 4
3.硬数据： 5
4.系统环境与约束： 5
5.涉众 5
6.涉众分析 6
7.问题域： 6
8. 主要特性 8
3.项目需求分析规格书。 10
引言： 10
- 撰写目的 10
- 需求背景 10
- 系统概述 11
4 系统特性 11
5、非功能性需求 17 - 数据存储 18
7.项目环境与前景 19
四、需求分析应有需求测试与改善计划 19
1.需求测试 20
2 改善计划 21
五、项目Glossary 21
1 Functional requirements 21
2 Requirements specification 22
3 Data Flow Diagram 22
4 User story 22
5 Use case 22
6 Activity Diagram 22
7 Organization Chart 22
8 Performance Requirements 22
9 Fault Tolerance 23
10 Soft Skills 23
11 Change Control Board 23
12 Legacy System 23
13 Incremental Development 23
14 Software Maintainability 23
15 focus of control 23
16 Requirement Specification View 24
17 Application domain 24
18 Change Request 24
19 non-functional requirement 24
20 Base Mysql Model 24
六、参考文献 24
一、项目需求提案计划书
1.引言
从用户的需求、需求分析、和发展开始进行项目路径图的规划
1.1.项目的目的
我们提出开发一个名为“学生电费管理系统”的项目，该系统设计到学生对电费的查找，以及电费的缴费，能够方便学校、学生缴交电费。
1.2.项目提出背景
当前大部分高校对学生宿舍的电费收缴都是使用线下、现金进行缴费，该种缴费方式需要学生去缴费处排队进行缴费，这种传统的方式对学生来说比较不方便。
1.3.项目提出原因
学生电费管理系统可以辅助学校对学生宿舍电费收缴进行管理，减少线下的人员成本，同时帮助学生提高缴交电费的效率。
2.项目前景与范围
1、宿舍之间具有一定的连续性，机动性，灵活性，使用该系统可以提高后勤管理人员的管理水平，对宿舍的工作进行科学、规范的管理，调动管理人员的工作积极性，提高了工作效率。
2、激发了后勤人员学习计算机的积极性，提高了后勤人员在广大学生心目中的形象。
3、调动后勤管理人员的工作积极性， 同时提高了办事的效率， 便于领导实施监督管理。
4、开创基层基础工作建设的新局面，增强后勤工作人员的工作热情，便于更好地管理 我们学校的后勤诸多琐碎事情的管理。
2.项目需求萃取分析书
引言：
顾名思义，需求获取就是进行需求收集的一个活动，它从人员.资料和环境中每到系使开发所，要的相关信息。
在传统的系统开发中.需求获取直是 一个被忽视的活动，无论是传统意义上的结构化开发还是20世纪90年代之后的面向对象开发，都以需求分析为需求处理的主要活动，并认为在需求分析之前各项需求就已经准备齐全了。这种“需求获得过程非常自然和顺畅”的看法使得传统的开发方法学没有在技术上对需求获取进行过多的考量。
20世纪90年代之后，随着软件系统规模和应用领域的不断扩大，人们在雷求获取中要面对的因难越来越多,因为需求的获取不充分而导致项目失败的现象也越来越突出。这时人们逐渐认识到需求获取和需求分析同样都是重要的需求处理活动开始接受需求获取的复杂性和因意性并为此发展出了很多解决困难的有法与技术
内容概要
软件需求的获取和分析是软件系统开发中的一项重要任务，正确获取软件需求是软件技术人员必须掌握的基本技能。本书从软件需求工程的角度出发，以需求开发过程为主线，完整描述了需求获取、需求分析、需求验证、需求规格说明和需求管理等需求工程活动。本书站在开发者的立场，侧重于实践者的技术与方法，系统全面地介绍了软件需求工程的各项进展，努力促进需求工程领域理论、方法和技术的全面融合应用，以指导需求工程各阶段的系统化实践。
1.需求获取与分析
编写目的：目前有些高校仍然采用线下缴纳电费的方法，这种方法在很大程度上十分的不方便，学校到了需要上缴宿舍电费的时候，需要在学校指定地点和指定工作人员的情况下，在规定的工作时间内排队才能让学生完成缴费，缴费的开放时间有规定并且很短，每次都是在高峰期进行开放，人多，排队缴费所花的时间太长，导致学生安排时间不够方便，而且学生也没办法随时随地的知道自己宿舍欠了多少电费。不方便的情况还有：一方面，为了缴纳电费，宿舍人员需要东奔西跑，去物业管理处查询，是否有未缴电费的记录，若未缴电费，则需要到相应的宿舍管理处刷校园卡进行缴费，程序较为复杂，浪费人力物力，管理学生宿舍缴费效率低;另一方面，缴纳电费后，学生仅得到一张小票，易遗失，宿舍人员无法在丢失小票的情况下不通过物业管理处知道宿舍缴纳电费的情况。因此根据调查，学生希望能够在网上随时进行宿舍电费的使用情况，电费余额、欠款、需上缴的金额等数据，并且提供网上缴费。
为了解决这种不方便需要采用线上缴费的方式，可使学生缴纳电费变得更加方便。
2.展开用户需求获取
首先展示数据方面，需要以宿舍为单位，因此需要将每个宿舍的信息记录到系统当中，宿舍信息包括 位置-几栋-具体房号。因此关于宿舍的具体信息是不会改变的，改变的应该是宿舍内部人员的信息。当宿舍人员更替的时候，宿舍人员信息也将更新。
因为数据库中存放的是宿舍信息，因此登陆可能可以使用一个宿舍一个账号登陆的方法。登录账号具体信息交由宿舍所有成员管理。或者是一个学生拥有一个账号，学生可以编辑个人信息，查询自己所在宿舍的用电情况，某宿舍某成员缴费成功后，与该宿舍相关联的学生账号有关用电信息也会改变。同时，管理学生信息的管理员在学生账号有效期结束后可以删除该账号。
查询用电情况，不能显示具体的用电细节，显示的是用电总数，可以查看宿舍的电费情况，同时需要提供上缴电费的标准，计算出需上缴的电费总数，以及缴费的开始与截止时间，缴费的开放时间通知应该在网站上的公示栏显示。
宿舍电费可以一次性交齐，也可以少交，少交则会产生电费欠款，多交则会产生电费余额，
所以需要管理每个学期的宿舍用电信息，所以缴费的信息会被保存下来。因此还可以查询往年的宿舍用电、缴费情况（包括缴费金额、具体时间）。因此管理员需要随时观察到未缴费或者未完全缴费的宿舍号，并且通过该宿舍提供的信息联系该宿舍补交电费。
由于学校有新生和毕业生，当毕业生住的宿舍的电费缴清之后，可以将该宿舍电费信息恢复为原始状态，从新生入住后开始重新记录用电情况。
要显示电费，则需要通过智能电表将用电数据实时传输到数据库当中，但是目前无法通过此方法实现，因此得依靠手工抄表将数据进行记录
3.硬数据：
选项 比例
一月一次 42.9%
两月一次 0
一学期一次 57.1%
以下是我们所进行的用户需求调查的关键数据表格。
您缴纳电费周期：
您平时是否清楚自己寝室的用电情况
选项 比例
一直清楚 42.9%
不在意，懒得查 28.6%
不清楚 28.6%
您支持网上缴费吗
选项 比例
排队时间长 74.1%
缴费点营业时间不确定 0
不能提前知道宿舍钱多少电费，现金准备过少 14.3%
4.系统环境与约束：
操作系统：win/7Win10系统
运行环境：通过网络登录网页端
网络架构：完全支持TCP/IP协议
5.涉众
对于系统的涉众分析，系统是面向学生宿舍的，因此其中一个利害相关者就是学生，同时所有学生宿舍信息以及缴费的相关数据需要进行管理，所以还会有一个管理员。
6.涉众分析
本项目涉及的主要使用人群是高校的学生。
高校管理员指的是学校方对系统进行管理的人，但是如果发生如学生未收到通知或有欠款，则此处可能通过对老师或者宿管进行通知，再由老师或宿管通知学生。
因此，该系统所涉及到的学校成员可以包括班主任、“宿管”。但是班主任、“宿管”本身不与该系统产生直接的关系。
管理员：指的是学校方对系统进行管理的人，但是如果发生如学生未收到通知或有欠款，则此处可能通过对老师或者宿管进行通知，再由老师或宿管通知学生。
因此，该系统所涉及到的学校成员可以包括班主任、“宿管”。但是班主任、“宿管”本身不与该系统产生直接的关系。
列如：
用户：高校学生、高校相关管理老师
软件开发者：软件工程6班第4组
软件管理者：软件工程6班第4组
7.问题域：
在现实世界的业务中，首先系统需要实现对登录的管理，由该系统的涉众分析来看，该系统的用户只有两类，因此需要对用户登录进行约束与限制。
7.1用户
用户端输入:学生通过自己的学号作为唯一认证可注册账号并且登录，管理员也可以通过自身管理员身份注册登录
Organization Chart
下图展示的是本系统的相关涉众人群结构图
使用目的：通过图表方式使系统的涉众结构更加清晰。
我们可以通过组织图（organization chart）清晰的看到用户的层次关系以及此系统有多少的用户
7.2网站权限
网站权限: 由于系统面向学校，因此只有在教务系统拥有学籍信息的学生和物管处的管理人员才能登录系统，其他人不能通过注册获取登录账号，
学生端：学生登录后可以设置头像、填写个人信息和绑定自己的所在宿舍号，但学号作为唯一认证不能做修改，绑定宿舍号后可以随时随地点击选择观看宿舍的和电的使用情况，用了多少度电或多少吨、宿舍需交多少电费、欠交多少、学生需要在什么时间前把拖欠电费（网站电费是月结的，每个月的一号前拖欠电费度数不能超过150度）和以前已经交的电费项目单，项目单上有单价、缴纳金额、剩余电量和缴费时间。可通过输入时间段来查询缴费记录。
管理员端：在需求获取的展开中，管理员需要观察到学生对费用的上缴具体细节，因此管理员的职责应该是对宿舍信息、学生用户信息以及缴费具体细节进行管理。
7.3自动计算
自动计算能力:由于需要显示需缴费用的具体细节，在管理员输入各宿舍用电度数以及相应单价后，系统将自动计算各宿舍需缴付的电费总额
自动计算可能会存在错误，因此需要每隔一段时间进行人工检查数据。
7.4学生更替
用户管理: 在需求获取的展开当中，由于学校会有新生和毕业生，因此对新生和毕业学生的信息需及时进行更新或删改操作，而此操作应当交由学校方面来进行管理。
当毕业生从学校毕业之后，宿舍电费有剩余时，学校方应当返还余额给学生，但是宿舍成员有多个，所以应当下发通知给宿管或者班主任，班主任或者宿管同一上交学生支付宝账号信息，统一发放。
7.5 网站统计
网站统计分析: 在学校内，如有关缴费的信息，都会通过学校下发官方的通知来通知学生进行缴费，因此我们需要通过统计数据，分析学生对系统的使用情况，如主动浏览网站关注水电费通知的学生占多少比例等等，在此基础上学校可以强化对学生的通知管理。
7.6公告与留言
公告和留言: 学校通知学生需要缴费的通知后，具体的细节如缴费的开始时间，缴费所需要注意的细节或者是相关重要通知，应当通过系统公告栏来进行显示，如电费单价更改以及缴费截止日期等
而学校方面可能需要收集学生关于校园缴费管理有何意见或者想法，因此需要提供一个留言板供同学对系统设计或水电费事项提出疑问或建议。
如果学生没有缴清宿舍相关费用，那么学校方管理员应该可以通知学生进行缴费，但是如果是在网页上进行通知，首先学生不一定会主动登录网页去查看所受到的信息，其次，宿舍多成员通知也比较繁琐，因此，此处应该采取的是管理员线下发布通知给学生用户，可以通过涉众分析当中的宿管来对学生进行通知。
7.7缴费
线下缴费都是上缴现金，而线上缴费则可以使用当今市场安全性较高的支付系统，如可以通过绑定微信或者支付宝来进行线上缴费。
该系统在核心功能缴费的问题上，所设计到的基本对象应该是一个宿舍，而宿舍内的成员有多个，因此在缴费上需要关联每个宿舍成员的信息。
此图是对系统整体功能进行描绘
8.主要特性
8.1特性
1：本系统将实现检索迅速和查找方便；信息的录入，修改和删除功能；以及对新入校学生进行入住登记等功能。系统提供多用户登陆，并实现用户之间简单的 角色管理，权限分配等功能。通过构建基于 Internet 的分布式网络信息共享平台，系统 用户能够在内网，或者是公网上登录系统，进行操作，实现学生宿舍管理工作的电子化管理。
2：本系统能提高学校宿舍管理部门的工作效率；充分利用资源；减少不必要的人力，物力和财力的支出；方便宿舍管理部门的工作人员全面地掌握学生住宿情况；提高学生对宿舍管理的互动性等。
3：系统设计应具有良好的易用性、操作简便，符合常规 Windows 操作环境下的用户使用习惯。同时，尽量减少用户的记忆工作量。服务器的故障将导致帮助文件 的内容不可访问，故建议服务器采用备份恢复的措施;；数据库的故障将导致某些功能的无效,但不影响帮助文件的查询。
 宿舍之间具有一定的连续性，机动性，灵活性，使用该系统可以提高后勤管理人员的管理水平，对宿舍的工作进行科学、规范的管理，调动管理人员的工作积极性，提高了工作效率。
(2) 激发了后勤人员学习计算机的积极性，提高了后勤人员在广大学生心目中的形象。
(3) 调动后勤管理人员的工作积极性， 同时提高了办事的效率， 便于领导实施监督管理。
（4）开创基层基础工作建设的新局面，增强后勤工作人员的工作热情，便于更好地管理 我们学校的后勤诸多琐碎事情的管理。
四、需求分析应有需求测试与改善计划
1.需求测试
1.1目的
在项目启动之后，就要着手软件项目的计划，包括需求测试计划。需求测试通常可以将用户需求转化为功能需求；其次，能将隐式需求转为明确。
1.2需求测试测试点
1）功能需求：指的是软件需要完成的功能；
2）非功能需求：不是指软件要完成的动作、功能，而是指其安全性、性能、是否符合法律法规等方面的属性；
3）限制条件：对项目具有限制性的属性。
1.3需求测试的方法
1）业务模型法：要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
2）业务场景法：要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。
3）功能分解法：业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数约束，权限约束
4）细节挖掘：
1.要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
2.尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。
1.4需求测试阶段需要做的工作
很多测试人员再需求阶段会比较茫然，不知道要做什么，其实做好真正的需求测试很重要，需要运用之前讲到的一些方法来进行需求测试，测试计划准备，测试方案准备，测试用例准备。
目前一些敏捷型开发，甚至都是采用的测试驱动，以测试用例为主导反推写代码。这样在某些方面开发出来的质量会更高。
A.测试需求，检查需求文档描述的正确性，整理出需求的疑问点，明确点，让所有人一致理解正确的需求。
可运用的方法：路径分析法（业务模型，场景分析）。
B.测试用例编写，从界面，从业务，从功能出发。
因果分析法，边界值法，等价类划分法，错误推测法（反向测试用例）等。
C.缺少需求文档时，那就要发挥测试人员的主管能动性了。
1.5需求测试的流程
需求测试——用例编写——测试执行——回归稳定——维护。
但是实际上用例编写时还要和产品确认需求。
1.6不断变化的需求对需求测试的影响
1）测试不断的理解需求，时刻维护测试用例。
2）测试时间无法保证，测试进度无法评估，测试质量无法保证。
3）面对不断变化的需求，我们应该站在用户的角度思考需求的问题，主动确认了解需求。
4）领导者:面对不断变化的需求我们需要对需求变化带来的工作量和风险进行评估，需要和产品研发明确产品质量要求，测试范围，需要协调的资源（浏览器，手机型号等）和时间。
1.7需求测试问题分类
1）需求完整性：将实现功能描述清楚；
2）需求可测性：可以通过用例或者其他方法验证；
3）需求一致性：需求上下文，需求原型之间一致；
4）界面元素：界面布局等易用性问题；
5）异常分析和容错处理：深入考虑可能导致的异常情况；
6）需求建议：分问题类别，主要个人观点。
2 改善计划
软件的需求在软件的发展过程中会不断发生变化，因此最终根据需求得出的软件功能也不会完全一样，可能会存在相似的功能。
为了在项目中加入独具特色的功能，我们需要时刻关注用户群体对项目系统的需求变化，不断优化需求规格说明书，在原有的基础上，加入一些独特的元素以吸引用户群体。
五、项目Glossary
1 Functional requirements
功能需求定义了系统应该做什么。如果不满足功能需求，系统将无法满足用户和涉众的期望。它不能正常工作或按预期工作，它规范记录了系统必须能够执行的操作和活动。
功能性需求就是在进行需求分析之后，对系统能够完成的事情（行为）进行的描述，在描述系统的功能性需求的时候，应该确定每个功能需求由谁、做什么以及原因。如果需求太大的话，可以将需求分为几个小部分进行描述。描述功能需求时，可以向用户描述他们该如何成功、正确地使用系统。
2 Requirements specification
用户需求规范描述了用户从系统中所需的业务需求。用户需求规范是在验证过程的早期编写的，通常是在创建系统之前。它们由系统所有者和最终用户编写，由质量保证部门提供输入。
用户需求规范不是一个技术文档，它是一系列过程的结果，这些过程是收集和记录描述系统的信息。它可以帮助开发者清楚地认识到用户的需求，帮助团队阐明业务需求。同时可以帮助团队创建测试计划，以验证系统是否确实适合目标用途。
3 Data Flow Diagram
数据流图（DFD）是可视化系统内信息流的传统方法。一个简洁明了的DFD可以用图形化的方式描述大量的系统需求。它可以是手动的，自动的，或者两者的结合。是数据进出信息系统的结构化显示。数据流图中的细节根据分配给它的级别而变化。
4 User story
随着项目的进展，需求总是随着团队和客户对系统的了解而变化。期望项目团队计划一个静态的需求列表，然后在几个月后交付功能性软件是不现实的。用户故事映射是一种更好、更灵活的方法，可以解决最终用户需求的严格变化。
5 Use case
用例捕获了系统涉众之间关于其行为的契约。用例描述了系统在各种情况下的行为，当系统响应一个利益相关者的请求时，称为主要参与者用例，基本上是一种文本形式，尽管它们可以使用流程图、序列图描述。用例作为一种写作形式，可以激发团队对即将到来的系统的讨论。
6 Activity Diagram
活动图直观地显示了系统中的一系列操作或控制流，类似于流程图或数据流图。活动图通常用于业务流程建模。它们还可以描述用例图中的步骤。建模的活动可以是连续的和并发的。在这两种情况下，活动图都有一个开始（初始状态）和一个结束（最终状态）。
7 Organization Chart
组织结构图的定义是显示报告或关系层次结构的图表。组织结构图最常见的应用是显示企业、*或其他组织的结构。组织结构图有多种用途，可以以许多不同的方式进行结构化。
8 Performance Requirements
对于每种不同类型的用户-计算机交互，大多数时间要经历的最大满意响应时间，以及大多数时间的定义。响应时间是从用户执行说“ Go”（开始）的操作开始直到用户从计算机接收到足够的反馈以继续执行任务为止的时间。这是用户的主观等待时间。
9 Fault Tolerance
容错是计算机系统的一种质量，可以很好地处理组件硬件或软件的故障。如果一个系统在一个或多个系统故障情况下继续令人满意地运行，则该系统可以描述为容错的。
10 Soft Skills
软技能与你的工作方式有关。软技能包括人际（人际）技能、沟通技能、倾听技能、时间管理和同情等。
招聘经理通常会寻找具有软技能的求职者，因为他们能让人在工作场所更成功。有些人在技术和工作技能方面可以表现出色，但如果他们不能在团队中管理时间或工作，他们可能就不会在工作场所取得成功。
11 Change Control Board
“变更评审委员会”（Change Control Board，也称为CCB）是指项目团队或项目组中的任何一组个人，他们负责最终决定何时以及是否要对工作产品或进度事件进行任何特定的变更。变更控制委员会决定何时以及是否应该进行一系列变更的过程是双重的。首先，变更控制委员会需要审查和研究拟议变更对相关项目的影响，然后，在进行评估之后，变更控制委员会可以批准变更、拒绝变更，或者在某些情况下，请求更多信息或推迟决策，等待其他事件的发生这将成为他们最终选择的因素。实际上会影响基线的重大变更几乎总是通过构型控制委员会批准。
12 Legacy System
遗留系统，在计算的上下文中，指的是过时的计算机系统、编程语言或应用软件，而不是可用的升级版本。
13 Incremental Development
迭代和增量软件开发从计划开始，并通过迭代开发周期持续进行，包括持续的用户反馈和功能的增量添加，最后在每个周期结束时部署完成的软件。
14 Software Maintainability
它基本上定义了维护系统的容易程度。这意味着分析、更改和测试应用程序或产品是多么容易。
15 focus of control
控制是测量实际性能，与标准性能进行比较，找出偏差并采取措施检查偏差。在一个小型组织中，管理者可以通过采用适当的控制手段来检查成员的每一项活动，但随着组织规模和复杂性的增加，管理者无法单独控制组织的所有活动。他们从事许多重要的管理活动，以检查和控制每一项组织活动。此外，这是昂贵和耗时的。因此，管理者应该关注最能反映组织目标的关键点或控制区域。
16 Requirement Specification View
需求规范是描述软件将执行的操作以及预期执行内容的文档。它还描述了产品满足所有利益相关者（业务、用户）需求所需的功能。
17 Application domain
应用程序域为安全性、可靠性和版本控制以及卸载程序集提供了隔离边界。应用程序域通常由运行时主机创建，运行时主机负责在应用程序运行前引导公共语言运行时。
18 Change Request
变更请求是变更管理过程中的一个重要文件，它陈述了应用程序或系统中变更的数据和原因。变更请求是一个声明性文档，这意味着它有关于需要实现什么、如何实现变更以及其他相关信息的清晰简洁的信息。
19 non-functional requirement
非功能性需求通常与系统状态相关，而与系统必须提供的功能无关。系统的一般“能力”，如可伸缩性、互操作性、可维护性、可移植性、性能和安全性都属于这一范畴。敏捷团队通常很难定义和评估项目中的非功能性需求。
20 Base Mysql Model
基于MySQL数据库模型，描述数据库的模型
六、参考文献
[1]《需求分析 软件需求与建模 第2版》骆斌 丁二玉著 2015.2