1 需求提案计划书

1.1 项目背景

随着社会的发展，人们的生活水平不断提高，人们对汽车这类交通工具越来越依赖。大量的人们开始学习汽车驾驶技术，于是众多的汽车培训学校产生了。为了提高驾校内部的管理水平和工作效率、降低费用和成本，企业需要建立现代化的应用系统。方兴未艾的驾驶培训行业尽量规模不断壮大，但大部分驾校仍然停留在手工作业阶段，随着很多驾驶培训中心不断发展和壮大，随之也带来了许多管理上的不足和困扰，现行的管理方式和管理体制不仅无法满足企业的发展的需要，还浪费了企业大量的人力和物力，降低了工作效率，也成为企业发展的绊脚石。因此，为了提高驾驶培训中心的业务管理水平和效率，降低运营成本，并适应不同的学车人员的个性化要求，以及新交规在驾驶培训方面的严格要求，急需开发一套驾校预约管理系统。

1.2 目的

驾校培训预约系统是通过对驾校各个资源管理中核心要素的闭环整合，实现了工作流、信息流、资源流和办公自动化的整合管理，提供了一个科学、开放、先进的驾校信息化管理平台，实现了学员信息管理、教练信息管理、约车信息管理等内容的高度集成。驾校培训预约系统将驾校管理人员从繁琐、无序、低序、低端的工作中解放出来从事核心事务，整体提高了信息办理速度和驾校管理信息的可控性，降低了管理成本，提高执行力，使驾校信息管理趋于完善。

1.3 项目前景

该产品在需求上充分考虑了具体学员用户、教练用户、驾校管理员的实际情况。本产品将主要适用于各驾校的驾校培训预约系统，主要完成学员信息管理、教练信息管理、学员预约培训时间、学员评价教练等业务，也可作为驾校统计学员通过率、报名人数等数据统计模块，可以得到更加直观的可视化数据，减少人工整理统计操作。本系统可行性较高，未来可以广泛运用于各大驾校。

1.4 项目路线图

适用环境：实现更加完善的需求分析。

使用目的：系统描述了系统开发路线。

绘制步骤：与开发人员进行讨论，根据实际开发能力进行绘制。

图例说明：使开发路线具体化，透明化，让开发人员更加容易地明白当前项目进度以及下阶段的任务。

1.5 能力路线图

适用环境：实现更加完善的需求分析。

使用目的：系统描述了能力路线。

绘制步骤：通过与开发人员的讨论，绘制适合团队的能力路线图。

图例说明：使团队对能力路线更加清楚，提高开发效率。

1.6 业务激励模型

适用环境：实现更加完善的项目计划书。

使用目的：系统描述项目的发展计划，分析影响因素。

绘制步骤：从系统的推广方式入手，预测潜在的竞争者。

图例说明：该图较为详细的描述了项目未来的发展期望。

1.7 动机视图

适用环境：该视图可用于分析指导组织及其企业架构的设计或变更的动机或原因。使用目的：这种观点代表了发展努力的愿景——无论规模和范围是包括整个组织，还是仅仅是组织的一部分(如业务线)，还是单个计划或项目(解决方案级别)。。

绘制步骤：根据原则提出目标，进而上升到组织的发展愿景。

图例说明：这些动机分析是组织中所有变革活动或业务转型的起点。

1.8 原则观点

适用环境：原则观点模拟了目标与原则之间的关系。

使用目的：聚合关系模拟了目标的分解，而实现关系模拟了原则如何与一个或多个目标相关联，从而更好的分析发展目标。

绘制步骤：从原则出发，根据原则分析目标。

图例说明：该图对项目提供了比较详细的目标和原则之间的关系。

1.9 总结

综合以上因素，我们小组选择了驾校培训预约系统作为课题，对它展开了详尽的分析。

2 需求萃取分析书

2.1 问题域分析

伴随国民经济的飞速发展和人民生活水平的不断提高，家用汽车在我国逐渐普及。面对不断增长的庞大的用户群，随之产生的驾驶培训行业，规模不断扩大。同时互联网已经成为人们日常生活，学习办公中不可缺少的组成部分，而随着互联网的不断普及，网络技术也得到了快速的发展。人们不再满足于传统的低效的办公方式，迫切需要一种高效的方式代替传统的方式，以适应社会的发展。而网络是解决由于物理距离造成的信息交流不畅、协商沟通不便的管理瓶颈问题的最佳方式。于是各种驾校培训预约系统应运而生，它一比传统的办公方式更方便、快速、安全、经济的优势被驾驶培训行业所青睐。

2.2 涉众分析

2.2.1 涉众描述

（1）系统管理员

（2）教练员

（3）学员

2.2.2 项目角色组织图

适用环境：分析系统所涉及的用户角色。

使用目的：分析系统所涉及的用户角色，根据角色进而分析每个活动具有的用例。

绘制步骤：从涉众分析提取信息，从而绘制出组织图。

图例说明：图中每种角色的数量在系统中都不止一位，因此用数字表示数量是多个。

2.3 硬数据采样

传统方法通过填写表格来记录学员和教练信息以及预约信息，通过人工整理汇总成为总体统计报表。因此可向驾校咨询并查看实际工作表格的样式，从实际的表格中获取实际业务的信息流，同时可从中得到并验证提出的功能需求是否能满足用户。

2.4 用户需求

2.4.1 驾校系统管理员

传统的驾校管理是用普通记录簿来登记学员信息，较为先进的驾校使用的是Excel软件来管理。然而面对大量的学员信息，Excel的操作就显得十分繁琐而又费时费力。驾校系统管理员需要的是一个操作简单、同时又能使用移动设备进行驾校学员的信息管理，并且能对教练员也有一定的管理权限，另外还可以开设公告以及宣传模块进行布置对学员的公告、对外界的宣传。又可根据学员对教练员的评价满意度，监管教练员的教学情况，可根据情况对教练员做出一定的奖惩措施。

2.4.2 驾校教练员

以往教练员需要手动整理汇总所负责的学员预约培训申请，同时还需要判断查询学员是否符合预约培训的资格（考试间隔时间有一定的规定），而又需要优先给驾驶学习证明即将到期的学员优先安排培训，这样的过程重复性高，较为耗时。同时教练员也可以管理附属学员，调整学员信息，查看学员预约信息，撤销学员预约信息等操作。

2.4.3 驾校学员

学员以往预约培训都需要询问教练员所想预约时段是否能够预约，过程较为繁琐，若有驾校培训预约系统，则可直接在系统中完成预约操作。同时以往学员难以对驾校管理员评价教练，在系统中可以实现学员匿名评价教练，保护学员信息，而又能反馈到驾校教练员教学情况。由于不好的评价信息容易引起教练员与学员之间的矛盾，因此应避免让教练员看到评价人或评价信息。

2.4.4 用例图

适用环境：向他人表述不同角色分别具有哪些用例。

使用目的：系统描述了问题解决方案的内容，描述外部角色在与解决方案的交互中完成的任务与目标；同时从系统特性中抽取，找到系统特性中蕴含的外部角色及交互任务。

绘制步骤：通过问题域、涉众上进行获取问题和明确问题，对发现的每个问题进行“明确问题→发现业务需求→定义问题解决方案及系统特性”，得到每个问题的业务需求和解决方案，从而进行绘制用例图。

图例说明：该图分析了不同角色的用例，也包括了用例间的包含关系。

2.5 项目范围

该产品在需求上充分考虑了具体学员用户、教练用户、驾校管理员的实际情况。本产品将主要适用于各驾校的驾校培训预约系统，主要完成学员信息管理、教练信息管理、学员预约培训时间、学员评价教练等业务，也可作为驾校统计学员通过率、报名人数等数据统计模块，可以得到更加直观的可视化数据，减少人工整理统计操作。本系统可行性较高，未来可以广泛运用于各大驾校。

2.6 系统环境

驾校培训预约系统主要用于学员先在系统中注册登录后，完成个人信息后通过指定的接口进行培训预约。预约申请提交后由管理员审核，教练员确认，成功预约后会通过短信或微信通知。

管理员通过线上登录系统，查看学员的预约申请，对其预约进行审核，通过后发至教练员账号，再由教练员确认。

教练员通过登录系统，查看预约审核确认功能模块，确认是否通过学员的预约申请。

2.7 总结

本文详细的描述了驾校培训预约系统的需求，同时对功能需求进行了较为详细的描述。本文为了进一步的分析打下了坚实的基础，需求萃取分析书是进行分析需求规格的基础。

3 需求分析规格书

3.1引言

3.1.1 编写目的

编写该需求规格说明为了记录本次软件设计的需求分析是最终得到的结果，以及在以后软件设计师会用到的数据以及功能。

3.1.2 项目背景

随着社会的发展，人们的生活水平不断提高，人们对汽车这类交通工具越来越依赖。大量的人们开始学习汽车驾驶技术，于是众多的汽车培训学校产生了。为了提高驾校内部的管理水平和工作效率、降低费用和成本，企业需要建立现代化的应用系统。方兴未艾的驾驶培训行业尽量规模不断壮大，但大部分驾校仍然停留在手工作业阶段，随着很多驾驶培训中心不断发展和壮大，随之也带来了许多管理上的不足和困扰，现行的管理方式和管理体制不仅无法满足企业的发展的需要，还浪费了企业大量的人力和物力，降低了工作效率，也成为企业发展的绊脚石。因此，为了提高驾驶培训中心的业务管理水平和效率，降低运营成本，并适应不同的学车人员的个性化要求，以及新交规在驾驶培训方面的严格要求，急需开发一套驾校预约管理系统。

3.2.系统概述

3.2.1 概述

驾校培训预约系统是通过对驾校各个资源管理中核心要素的闭环整合，实现了工作流、信息流、资源流和办公自动化的整合管理，提供了一个科学、开放、先进的驾校信息化管理平台，实现了学员信息管理、教练信息管理、约车信息管理等内容的高度集成。驾校培训预约系统将驾校管理人员从繁琐、无序、低序、低端的工作中解放出来从事核心事务，整体提高了信息办理速度和驾校管理信息的可控性，降低了管理成本，提高执行力，使驾校信息管理趋于完善。

3.2.2 域模型

适用环境：在应用程序中加入域模型包括插入整个由对象组成的层，这些对象是对你正在操作的业务区域进行建模。

使用目的：域模型创建了相关关联的对象的网络，其中的每一个对象都代表了某些有用的个体，不管这个个体是大的有如一个公司，还是小的有如订单表单上的一行。

绘制步骤：根据业务涉及的人、事务等来确定项目的域模型。

图例说明：域对象可以代表业务领域中的人、地点、事物或概念。。

3.2.3 运行环境

（该系统是B/S三层架构，它的运行环境分客户端，应用服务器端和数据库服务器三部分）

（1）客户端：

操作系统：windows,Android，mac等智能设备

浏览器：chrome等主流浏览器

（2）应用服务器端：

操作系统： centos 7

应用服务器：Tomcat 8.5.51

数据库访问：JDBC

（3）数据库服务器端：

操作系统：centos 7

数据库系统：Mysql 5.8

3.2.4 假设与依赖

本系统要求必须是系统的用户才可使用，对于用户的身份开放相对应的权限。同时对于本系统的用户，必须具备使用互联网的条件和使用互联网的能力。当信息管理信息过于繁多和复杂,网络化管理必不可少。计算机技术和产品的发展日新月异,将会给信息处理带来更多的手段,同时也会带来更加丰富的信息表达形式。例如多媒体技术的发展,这些都要求系统在设计时考虑技术变化的可能性,为可能的变化预留一定的系统处理能力。

3.3.系统特性

3.3.1 系统角色

本系统主要用于以下的几类人员：

（1）系统管理员，系统用户管理，预约管理，评论管理，公告宣传管理。

（2）教练员，发布预约。

（3）学员，培训预约，评价教练

适用环境：需要清晰的了解系统所涉及的角色。

使用目的：分析系统所涉及的角色。

绘制步骤：根据涉众分析提取信息绘制而成。

图例说明：从图可以清晰的看出每种角色数量都为多个。

3.3.2 学员管理

3.3.2.1 增加学员

使用者：驾校有学员管理功能角色的用户

目的：单个添加学员基本信息

基本事件流：

1.用户进入增加单个学员界面，本用例开始。

2.系统显示学员信息输入界面，用户输入学员姓名、学号、性别、出生日期、入学日期，班级，政治面貌，籍贯。

3.用户确认输入信息，系统检查学号是否唯一，若唯一，则增加学员信息，本用例结束。否则，提示用户重新输入。

3.2.2删除学员信息

使用者：驾校有学员管理功能角色的用户

目的：删除单个学员基本信息

基本事件流：

1.用户进入删除单个学员界面，本用例开始。

2.系统显示学员信息界面。

3.用户确认学员信息，系统检查用户是否存在，若存在，则删除学员信息，否则提示用户错误。

3.2.3导入学员信息

使用者：驾校有学员管理功能角色的用户

目的：批量导入学员信息，也可以将其他系统中学员信息按照规定的格式导入本系统。

基本事件流：

1.用户进入批量导入学员界面，本用例开始。

2.系统显示导入文件类型，格式说明，并提供导入的模板文件下载。

3.用户按照导入文件格式要求填写或者生成对应文件，然后将文件上传，点击确定。

4.系统检查文件的合理性，如果文件格式有误或者有数据冲突，给出详细的提示列表（错误所在行，错误原因），用户修改文件后再上传，如果上传文件合理，系统将学员信息导入系统。

5.本用例结束。

3.3.3 教练员管理

3.3.3.1 增加教练员

使用者：驾校有教练员管理功能角色的用户

目的：单个添加教练员基本信息

基本事件流：

1.用户进入增加单个教练员界面，本用例开始。

2.系统显示教练员信息输入界面，用户输入学员姓名、教练员编号、性别、出生日期、入职日期，政治面貌，籍贯。

3.用户确认输入信息，系统检查教练员编号是否唯一，若唯一，则增加学员信息，本用例结束。否则，提示用户重新输入。

3.3.3.2 删除教练员信息

使用者：驾校有教练员管理功能角色的用户

目的：删除单个教练员基本信息

基本事件流：

1.用户进入删除单个教练员界面，本用例开始。

2.系统显示教练员信息界面。

3.用户确认教练员信息，系统检查用户是否存在，若存在，则删除教练员信息，否则提示用户错误。

3.3.3.3 导入教练员信息

使用者：驾校有教练员管理功能角色的用户

目的：批量导入教练员信息，也可以将其他系统中教练员信息按照规定的格式导入本系统。

基本事件流：

1.用户进入批量导入教练员界面，本用例开始。

2.系统显示导入文件类型，格式说明，并提供导入的模板文件下载。

3.用户按照导入文件格式要求填写或者生成对应文件，然后将文件上传，点击确定。

4.系统检查文件的合理性，如果文件格式有误或者有数据冲突，给出详细的提示列表（错误所在行，错误原因），用户修改文件后再上传，如果上传文件合理，系统将教练员信息导入系统。

5.本用例结束。

3.3.4 预约管理

3.3.4.1 发布预约

使用者： 具有发布预约功能的用户

目的： 发布驾驶培训预约信息

基本事件流：

1. 用户进入发布预约功能界面，本用例开始。

2. 系统提示用户输入培训信息

3. 用户输入培训详细信息，确认无误后提交

4. 本用例结束

3.3.4.2 审核预约

使用者： 具有预约审核功能的用户

目的： 审核教练员发布的预约信息和学员发起的培训预约

基本事件流：

1. 用户打开审核界面，本用例开始

2. 系统显示详细的预约信息

3. 用户确认预约信息是否无误，若无误，通过审核，否则，拒绝审核并通知相对应的用户详细情况，本用例结束

3.3.4.3 培训预约

使用者： 具有培训预约功能的用户

目的： 学员申请驾驶培训

基本事件流：

1. 用户打开培训预约界面，本用例开始

2. 系统显示详细的培训信息

3. 用户确认预约是否无误，若无误，发起预约等待审核，否则，退出预约界面。本用例结束。

3.3.5 评价管理

3.3.5.1 评价教练

使用者： 具有评价教练功能的用户

目的： 对教练员的能力进行评价

基本事件流：

1. 用户打开评价界面。本用例开始

2. 用户输入详细的评价信息

3. 用户确认输入是否无误，若无误，则提交，否则退出评价界面。本用例结束

3.3.5.2 管理评价

使用者： 具有管理评价功能的用户

目的： 管理学员对教练员的评价

基本事件流：

1. 用户打开管理评价界面

2. 系统显示详细的评价信息

3. 用户统计评价信息，本用例结束

3.3.6 公告宣传管理

3.3.6.1 发布公告

使用者： 具有发布公告功能的用户

目的： 发布通知

基本事件流：

1. 用户打开公告界面

2. 用户输入详细的公告信息

3. 用户确认公告信息，若正确则发布，否则重新编辑公告信息。

4. 发布成功后，用户退出发布公告界面。本用例结束

3.3.6.2 管理公告

使用者： 具有管理公告功能的用户

目的： 管理已发布的通知

基本事件流：

1. 用户打开管理公告界面

2. 系统显示详细的公告信息

3. 用户进行公告的管理，本用例结束

3.3.7 需求实现观点

适用环境：该模式通常在定义了目标、明确了需求和约束、设计了业务服务、流程和应用程序服务及组件的分析阶段使用。它也可以在应用程序或流程重新评估阶段使用。

使用目的：实现对需求和目标的结合。

绘制步骤：根据项目目标的分析、以及需求，结合绘制成为需求实现观点。

图例说明：显示目标、需求和业务和应用程序服务的核心元素之间的关系。

3.3.8 服务实现观点

适用环境：模拟了底层流程（有时是应用程序组件）如何实现一个或多个业务服务。

使用目的：为一个或多个业务流程上提供“外部视图”。

绘制步骤：根据业务流程以及它们所属的服务程序、对应的角色绘制而成。

图例说明：它形成了商业产品观点和业务流程视图之间的桥梁。

3.3.7 复合需求层次图

适用环境：完善需求分析。

使用目的：使开发人员更加容易理解需求。

绘制步骤：对业务进行分析，明确业务之间的关系，再利用ea工具对其进行描述。

图例说明：更加清晰地描述了需求之间的关系。

3.3.8 需求追溯图

适用环境：完善需求分析。

使用目的：更加清晰展示需求与需求之间的关系。

绘制步骤：明确每个需求之间的关系，再利用ea工具进行绘制。

图例说明：更加清晰地描述了需求之间的关系。

3.3.9 时序图

适用环境：分析系统的业务流程。

使用目的：完善系统的需求分析。

绘制步骤：对系统的业务进行分析，提取重要的业务流程，利用ea工具进行绘画。

图例说明：清晰地描述了系统的业务流程的进行顺序。

3.3.10 活动图

适用环境：分析系统的业务流程。

使用目的：完善需求分析。

绘制步骤：通过与客户进行交流，分析出每个业务的具体流程，利用ea工具进行绘制。

图例说明：清晰地描述了业务流程。

3.3.11 数据流图

适用环境：分析系统每个流程的数据传递方向和加工角度。

使用目的：表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程。

绘制步骤：对系统的业务流程进行分析，利用ea工具进行绘制。

图例说明：清晰完整地描述了系统地业务流程。

3.4. 非功能性需求

3.4.1 性能需求

响应时间：尽可能地短，达到1到2秒

预约统计时间不超过30秒

支持10000名学生信息一次性导入，导入时间不超过20秒

支持5000名用户并发使用，并保证性能不受影响

3.4.2 安全性需求

3.4.2.1 权限控制

根据不同用户角色，设置相应权限，用户的重要操作都做相应的日志记录以备查看，没有权限的用户禁止使用系统。学员只能查看自己的个人信息和预约记录；教练员只能查看自己的个人信息和发布的预约记录以及预约其课程的学员的记录；管理员只能查看已存在的用户的个人信息、发布的预约、所有课程的预约详情。

3.4.2.2 重要数据加密

对一些重要的数据按一定的算法进行加密，如用户口令，重要参数等

3.4.2.3 数据备份

允许管理员用户进行数据的备份和恢复，以弥补数据的破坏和丢失

3.4.2.4 记录日志

系统应该能记录系统运行时所发生的所有错误，包括本机错误和网络错误。日志同时记录用户的关键性操作信息

3.4.3 可用性需求

对于一个可用的系统，应满足如下要求：

1. 方便操作，操作流程合理

2. 控制必录入项

3. 容错能力

4. 统一规范的提示信息

5. 用户可自定义（一些重要参数可以灵活配置）

6. 联机帮助与操作指南

3.4.4 用户文档

包括：安装手册（word），用户手册（word），在线帮助

3.4.5 其他需求

(1)支持多浏览器

(2)系统安装访问方便

3.4.6 非功能需求图

适用环境：分析项目的非功能需求。

使用目的：明确系统的非功能需求。

绘制步骤：分析系统的非功能需求，再对其进行绘制。

图例说明：清晰地描述了项目的非功能需求。

3.5 外部接口需求

3.5.1 用户接口

本系统采用B/S架构，所有界面使用WEB界面，用户界面的具体细节将在概要设计文档中描述。

3.5.2 硬件接口

具有联网功能的通讯设备，如手机、电脑等。

3.5.3 软件接口

无特殊需求。

3.5.4 通信接口

无特殊需求。

3.6 项目部署图

适用环境：部署项目。

使用目的：方便项目上线部署。

绘制步骤：明确项目需要的服务以及每一个层次之间的关系。

图例说明：更加清晰地描述了项目的部署路线。

3.7 数据库安装图

适用环境：具体描述了数据库的安装。

使用目的：完整、详细的教程给开发人员等使用。

绘制步骤：根据实际安装数据库过程绘制而成。

图例说明：让不熟悉数据库使用的人员学会安装数据库等操作。

3.8 创建新的数据库

适用环境：项目开发前创建数据库。

使用目的：完整、详细的创建数据库教程给开发人员等使用。

绘制步骤：根据实际创建数据库过程绘制而成。

图例说明：让不熟悉数据库使用的人员学会使用创建数据库。

3.9 总结

本文详细的描述了驾校培训预约系统的需求规格，同时对各种需求进行了较为详细的描述。本文可作为后续系统设计依赖的一些规格要件。

4 需求测试与改善计划

4.1 需求测试

    由于软件系统的复杂性，在需求分析阶段可能存在着开发方对委托方业务需求理解不全面、不准确的情况。在这种情况下，如果不进行相关的质量控制，往往会造成开发结果与用户需求不一致的后果。需求测试的目的就在于保证软件设计最大可能地满足有关用户的所有需求，降低额外风险和未预料的成本。

    通过开展需求测试，测试人员应能及时发现需求定义中存在的问题，使相关单位在认知上达成一致，采取有效的预防措施，降低变更的成本；更好地理解产品的功能性和非功能性需求，为制定测试计划和用例打下基础。

    人工的静态分析是需求测试中最常使用的手段，测试人员可以通过需求评审和设计测试用例的方式来测试需求。

    需求评审必须要有用户或用户代表参与，同时还需要包括项目的管理者、系统工程师、相关开发人员、测试人员、市场人员、维护人员等。在项目开始阶段就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏部分人员的意见，导致需求的缺失。

    对需求的评审应从以下几个方面进行：

完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。

无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：每项需求的制定都是必要的且能够追溯的。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。

4.2 改善计划

在需求分析已经基本完善了的情况下，我们在后续的系统设计中也需要不断验证需求，若需求验证产生问题，则需要不断修正需求，预防需求分析错误，进而导致项目最终失败。

另外项目应不断进行迭代，顺应时代的发展，不能停留在某一个版本而不加以改进、增添客户所需的功能。尽可能的满足客户的需求，逐步转型发展吸引高端客户，发展定制服务，提高收益。

5 项目Glossary

参考文献

[1]王珊，萨师煊．数据库系统概论[M].北京:高等教育出版社，2006.5.78-259.

2006.1.47-90.

[2]骆斌，丁二玉．需求工程——软件建模与分析（第2版）[M].北京:高等教育出版社,2015.2.75-245

小组期末报告 G003-185-12

原文：https://www.cnblogs.com/CSJhzu/p/14203114.html