《教学课件：《软件需求：理论与实践》》由会员分享，可在线阅读，更多相关《教学课件：《软件需求：理论与实践》（447页珍藏版）》请在金锄头文库上搜索。
1、需求 工程 基第一章础目录1.1 什么是软件需求？1.2 软件需求的分类1.3 软件需求工程及过程1.4 补充说明什么 是 软1.1件 需 求什么是软什么是软件？件？（1）软件是一系列按照特定顺序组织的计算机数据和指令的集合。软件可以说是程序加文档的集合。软件=数据结构+算法+文档常见的软件：系统软件应用软件中间件操作系统支撑软件管理计算机硬件与软件资源的程序，是计算机系统的内核与基石。管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备，操作网络与管理文件系统等基本事务，是用户和计算机的接口。支撑系统中各种软件的开发与为维护的软件，又称为软件开发环境，主要包括环境数据库、各种接口软
2、件和工具组。如微软公司的VisualStudio.NET。为了某种特定的用途而被开发的软件，为了满足用户不同领域、不同问题的应用需求而提供的。可以是一个由众多独立程序组成的庞大的软件系统，例如qq，word，淘宝等。中间件是一类连接软件组件和应用的计算机软件，包括一组服务。它位于客户机/服务器的操作系统之上，管理计算机资源和网络通讯。通过中间件，应用程序可以工作多平台或操作环境中。比如：tomcat，jboss,weblogic,websphere等软件。（2）软件的）软件的分类：分类：什么是软件什么是软件工程？工程？（1）【IEEE1990】关于软件工程的定义软件工程是：将系统化的、严格约束
3、的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；指在中所述方法的研究。目前比较认可的一种定义是：软件工程是研究和应用如何以系统化、规范化、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。（2）软件工程的各）软件工程的各个阶段：个阶段：项目计划项目计划需求分析需求分析传统需求处理认为：该阶段为需求处理过程。系统化的需求工程认为：软件工程前期的需求工作+软件工程的需求分析阶段=软件需求工程（2）软件工程的各）软件工程的各个阶段：个阶段：项目设计项目设计编码编码（2）软件工程的各）软件工程的各个阶段：个阶段：测
4、试测试发布与维护发布与维护（3）软件需求工程在系统工）软件需求工程在系统工程的位置程的位置软件需求工程包括软件需求分析阶段以及在此之前做的有关系统的所有需求的工作。这里的系统指“系统工程”的概念。该图为软件需求工程在系统工程中所处位置。若您对系统工程有兴趣，可以查阅相关资料，了解系统工程。需求工程师就产生于软件需求工程中。什么是需求？什么是需求？IEEE1990对需求的定义：（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；（3）对上述两种情况（1）或（2）中的一个条件或一种能力的一种文档化表述
5、。什么是需求？什么是需求？-动画故事动画故事“我要一只羊我要一只羊”小小P P刚刚加加入入一一个个项项目目组组，项项目目经经理理安安排排他他做做需需求求分分析析，小小P P有有点点不不乐乐意意：“需需求求有有什什么么好好分分析析的的啊啊？客客户户要要什什么么就就给给什什么么呗呗，简简直直浪浪费费我我这这个个人人才才！” 一一天天，客客户户打打电电话话说说：“我我要要一一只只羊羊”。小小P P一一听听，太太简简单单了了，写写下下了了需需求求：“XX“XX客客户户需需要要一一只只羊羊。”小小P P叫叫小小Q Q去去处处理理这这件件事事。小小Q Q觉觉得得很很简简单单，抓了一只羊就送过去了。抓了一只
6、羊就送过去了。 结结果果客客户户的的投投诉诉第第二二天天就就来来了了，项项目目经经理理黑黑着着脸脸训训斥斥小小P P，小小P P觉觉得得委委屈屈：“我我是是按按照照客客户户的的要求做的呀，怎么就错了呢？要求做的呀，怎么就错了呢？”亲爱的，你知道小亲爱的，你知道小P为什么挨批了吗？为什么挨批了吗？软件危机软件危机?软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。产生软件危机的其中一个原因：用户需求不明确用户需求不明确在软件开发过程中，用户需求不明确问题主要体现在四个方面：在软件开发出来之前，用户自己也不清楚软件开发的具体需求；
7、用户对软件开发需求的描述不精确，可能有遗漏、有二义性、甚至有错误；放弃美丽的女人让人心碎软件危机软件危机?在软件开发过程中，用户还提出修改软件开发功能、界面、支撑环境等方面的要求；软件开发人员对用户需求的理解与用户本来愿望有差异。软件 需 求1.2的 分 类需求的分类需求的分类1.功能需求2.非功能需求性能需求质量属性对外接口约束业务需求why用户需求what系统需求how功能需求的三个功能需求的三个层次层次业务需求描述组织或客户的高层次目标，定义系统特性。通常来自于高层业务部门。业务需求从总体上描述了为什么要开发软件或系统（即Why），组织希望达到的目标。业务需求获取后形成的文档为项目前景和
8、范围文档。这些文档描述了组织对将使用的软件系统所要达到的目标的预期期望。用户需求主要指用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务。用户需求主要描述了用户使用系统能够做什么事情（即What）。通过用户需求信息形成的文档为用例说明文档。系统需求是用户对系统行为的期望，一系列的系统需求联系在一起，帮助用户完成任务，达成用户需求，进而满足业务需求。系统需求可以直接映射为系统行为，定义系统中需要实现的功能，描述开发人员需要实
9、现什么。它描述的是开发人员如何设计具体的解决方案来实现这些需求（即How），是业务需求和用户需求最终实现的目标，其级别比用户需求高一个数量级。系统需求信息都记录在需求规格说明（SoftRequirmentsSpecification即SRS）文档中。系统需求系统需求HOW指的是需求怎指的是需求怎样实现的吗？样实现的吗？需求怎样实现是在设计阶段完成，所以是错误的。How指需求本身的流程。可以简单理解为系统功能（what）的实现流程。三种功能性需求中，猜猜哪个需三种功能性需求中，猜猜哪个需求最重要？求最重要？如果业务需求错了，那么，需求也就完美地错误了。业务需求是需求的驱动力，是需求的价值所在。需
10、求的最终目的就是解决客户的问题。观观看看情情景景篇篇或或者者动动画画片片： （3030秒，展示秒，展示M M餐厅现在存在的问题。）餐厅现在存在的问题。）M餐厅由于有特色，菜品丰富等优点，名气越来越大，而店面规模有限，出现了餐饮高峰时期顾客人满为患的情况，顾客就餐氛围差、环境嘈杂，大批顾客因排队时间过程而产生不满情绪或直接离开。M M餐厅老板的需求：餐厅老板的需求：M餐厅老板为了在扩充店面尚未完成的情况下，尽可能增加顾客好感度，防止新老客户流失，想要一个餐厅专属APP，（本课程中统一命名为Android点餐系统），用来向顾客提供餐厅信息，和一些预约订餐功能，节约顾客的等候时间，增加顾客的满意度，
11、减少顾客排队困扰，提升餐厅的名气。开开发发线线上上点点餐餐系系统统（本本课课程程中中统统一一命命名名为为AndroidAndroid点点餐餐系系统统），来解决一部分问题来解决一部分问题1.1.功能需求三个层次功能需求三个层次举例举例（1）业务需求（Why）：YW1：实现订餐的有效管理高层次的解决方案SS1：在线下单、后台管理，实现统一有效管理。系统特性SF1：客户需要订餐时在线下单、选座。餐厅后台查看订单准备菜品。注意特色菜优先展示给客户。（2）用户需求（What）UR1：在需要订餐时，选择相关菜品及座位信息，填写顾客相关信息，提交订餐单，等待餐厅反馈信息，并根据反馈信息查看订餐及选座是否成功
12、。补充说明PD1：订餐单的内容包括：订餐人，联系方式，订餐日期，用餐日期，菜品信息，总价，人数，座位信息，特殊说明，.订餐单的反馈内容包括：订餐人，餐厅信息，订餐日期，用餐日期，菜品信息，总价，人数，座位信息，特殊说明，订餐是否成功，.1.1.功能需求三个层次功能需求三个层次举例举例（3）系统需求（How）SR1：消费者可以在移动设备上随时查看餐馆所有的菜目、价格、数量等信息。消费者可以在移动设备上（手机、平板）下单，预订座位，可以取消或修改订单。餐馆业务人员可以实时查看并处理订单。餐馆业务人员可以更新菜品信息，对系统用户数据进行管理等。1.1.功能需求三个层次功能需求三个层次举例举例2. 2
13、.非功能需求非功能需求（1）性能需求IEEE1990对性能的定义：一个系统或者其组成部分在限定的约束下，完成其指定功能的程度。主要包括用户在软件响应速度、精度、容量、负载、系统吞吐量，运行时资源消耗等属性要求。2.2.非功能需求非功能需求（1）性能需求 例如，Android点餐系统中涉及的精度要求:PR1：餐馆要求每笔订单交易误差不得超过1角，每天交易额的误差不得超过100元。时间特性的要求： 前台客户端 PR2:要求登录时间不得超过0.5秒，选择菜品、座位后下单的响应时间不得超过1秒，其他的一些操作响应时间一般不得超过0.5秒。后台服务器 PR3:要求管理员操作保持流畅，用户下单后后台需要在
14、5秒内看见用户的订单。例如：Android点餐系统负载的要求：PR4：系统应允许同时有200人在线点餐。注意，性能需求的定义要适合运行环境，过于宽松的性能要求会带来用户的不满，过于苛刻的性能要求会给系统的设计造成不必要的负担，所以给出一个合适的量化标准非常关键，同时又非常困难。常见的方法是在限定性能目标的同时给出一定的灵活性或者给出不同层次的目标要求。例如：PR5:（最低标准）在200个用户并发时，系统不能崩溃。（一般标准）在200个用户并发时，系统应该在80%的时间内正常工作。（最高标准）在200个用户并发时，系统保持正常工作。2. 2.非功能需求非功能需求（2）质量属性系统完成工作的质量，
15、即系统需要在一个“好的程度”上实现功能需求，如软件的灵活性、高效性、可靠性、可维护性、健壮性、可用性等。2. 2.非功能需求非功能需求（2）质量属性灵活性:产品在增加新功能时所需工作量的大小如：QR1：要求5年内价位在500元以上的Android手机都可以流畅运行Android点餐系统，服务端要求保持可移植性，方便硬件设备的更换。可靠性：软件无故障执行一段时间的概率，如QR2：由于软件失效引起实验失败的概率应不超过5%。健壮性：指的当系统或软件遇到非法输入、相关软件或硬件组成部分的缺陷或异常的操作情况下，能继续正确运行功能的程度。圆圈4，易用性与可用性：用户理解软件时所花费最小化程度，软件在出
16、现系统故障后保持运行的能力。如：QR3：Android点餐系统客户端要求符合大众操作习惯，与网上其他的Android系统App操作方式保持基本一致。系统维护期间应保证系统能正常工作。2. 2.非功能需求非功能需求（3）对外接口系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。对系统之间的软硬件接口需要说明以下内容：接口数据格式接口命令格式接口标准接口输入输出接口用途2. 2.非功能需求非功能需求（3）对外接口系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。例如：IR1:Android点餐系统中要求手机系统版本Android2.2及以上版
17、本，手机数据线接口，电脑硬件配置，电脑系统软件要求等。2. 2.非功能需求非功能需求（4）约束构建系统时需要遵循的约束，如编程语言和硬件设施等。约束不受系统功能需求影响，却会给系统开发带来很多限制，会在总体程度上限制开发人员设计、开、测试时的选择范围。2. 2.非功能需求非功能需求（4）约束例如：Android点餐系统对移动设备和服务器的软硬件要求： 1. 硬件要求 前 台 客 户 端 运 行 在 环 境Android2.2及以上版本的移动设备上。服务器可以运行在常规的桌面机上，需要配置 JDK、tomact服务器 、MySQL数据库。 2. 系统的软件要求（1）客户端操作系统：Android
18、2.2以上系统（2）服务器端操作系统：Windows2000 Server或更新版本。 数 据 库 系 统 ： MySQL Server5.4或更新版本。可利用的信息和资源：互联网信息，餐馆3. 条件、假定和约束（1）5年内的Android手机都可以使用此点餐系统。（2）所建议的系统的运行寿命的最小值：3年（3）后台服务器只提供硬件服务器，并且预算为1万元，服务器的软件没有预算。（4）点餐系统可以通过互联网连接系统完成点餐。（5）开发期限3个月，过期没有交付赔偿违约金1万元。需求 工程 基第一章础目录1.1 什么是软件需求？1.2 软件需求的分类1.3 软件需求工程及过程1.4 补充说明软件需
19、求1.3程工及程过1.3软件需求软件需求工程工程需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。1.3软件需求工程：（后续章节会软件需求工程：（后续章节会详细介绍）详细介绍）过程是一系列活
20、动集合，通过这些活动的执行，可以完成一项任务或者达到一个目标。需求工程过程就是一系列与需求开发、管理相关的活动。包括：需求获取，需求分析，形成需求规格说明文档，需求验证，需求管理1.3软件需求工程：（后续章节会软件需求工程：（后续章节会详细介绍）详细介绍）1.需求获取需求获取从涉众、文档资料或者环境中获取需求的过程，包括收集背景资料，定义项目前景和范围，选择信息来源，选择获取方法或技巧，记录获取结果。1.3软件需求工程：（后续章节会软件需求工程：（后续章节会详细介绍）详细介绍）2.需求分析需求分析是指建立一个新的或改变一个现存的系统时描写新系统的目的、范围、定义和功能时所要做的所有工作。需求分
21、析是软件工程中一个关键过程。在这个过程中要分析背景资料、确定系统范围、细化需求、确定优先级，协商需求，确定需求。确定需求后分析和寻求新系统的解决方法，需求分析阶段的任务是确定软件系统功能。1.3软件需求工程：（后续章节会软件需求工程：（后续章节会详细介绍）详细介绍）3.需求规格说明需求规格说明书是指将获取的需求需要编写成文档，方面在用户、客户或开发人员之间交流需求信息，是整个开发工作的基础。其内容包括硬件、功能、性能、输入输出、接口界面、警示信息、保密安全、数据与数据库、文档和法规的要求。1.3软件需求工程：（后续章节会软件需求工程：（后续章节会详细介绍）详细介绍）4.需求验证需求验证是用来确
22、保需求说明准确、完整地表达需求需要，主要包括审查需求文档，修正不合理的需求。1.3软件需求工程：（后续章节会软件需求工程：（后续章节会详细介绍）详细介绍）5.需求管理需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。其活动包括：定义需求基线，建立跟踪信息，进行变更控制。需求 工程 基第一章础目录1.1 什么是软件需求？1.2 软件需求的分类1.3 软件需求工程及过程1.4 补充说明补充 说 明1
23、.4补充补充1：作业环节：作业环节-作业准备作业准备要求自发现提出一个DirtyExample。（注：DirtyExample是一个课题名称，可以是您生活中发现的某个问题，想要用软件实现。也可以是发现已有软件的问题后，自己想要重新开发一款软件解决已有问题。课题名称您自己定。可以是一个小型信息管理系统，或者一个网站。后续作业要求完成该课题的一系列工作，最终产生解决方案。课题要求的核心功能一到二个就可以，不可太大太难，以免影响后续作业的完成。登陆和注册不算核心功能。）补充补充2：优秀需求特性（请您查阅：优秀需求特性（请您查阅资料自学）资料自学）1.完整性完整性2.正确性正确性3.精确性精确性4.可
24、行性可行性5.必要性必要性6.无歧义无歧义7.可验证可验证补充补充3：常见的需求定义错误（请：常见的需求定义错误（请您查阅资料自学）您查阅资料自学）1.需需求求并并没没有有准准确确反反映映用用户户的的真真实实需要需要2.需求定义模糊需求定义模糊3.需求信息不完整需求信息不完整补充补充4：社会对需求工程师的知识：社会对需求工程师的知识和技能要求（请您查阅资料自学）和技能要求（请您查阅资料自学）1.需求工程师的任务需求工程师的任务（1）根根据据项项目目要要求求，对对客客户户进进行行需需求求调调研研，整整理理用用户户需需求求（2）进行需求分析，完成用户需求说明书编写）进行需求分析，完成用户需求说明书
25、编写（3）负负责责给给客客户户演演示示完完成成的的项项目目模模块块，并并收收集集完完成成模模块块的意见的意见（4）协协助助系系统统架架构构师师、系系统统分分析析师师、开开发发人人员员对对需需求求进进行理解行理解（5）整整理理分分析析客客户户需需求求，对对其其分分类类并并实实现现评评估估，完完成成需需求分析报告求分析报告（6）指指导导测测试试工工程程师师根根据据测测试试需需求求，组组建建测测试试环环境境的的工工作作补充补充4：社会对需求工程师的知识：社会对需求工程师的知识和技能要求（请您查阅资料自学）和技能要求（请您查阅资料自学）2.需求工程师需要具备的知识：需求工程师需要具备的知识：（1）计算
26、机专业基础知识）计算机专业基础知识（2）建模方面知识）建模方面知识（3）行业专业知识）行业专业知识（4）法律法规知识）法律法规知识（5）社会学知识）社会学知识（6）心理学知识）心理学知识（7）语言学知识）语言学知识补充补充4：社会对需求工程师的知识：社会对需求工程师的知识和技能要求（请您查阅资料自学）和技能要求（请您查阅资料自学）3.需求工程师需要具备技能要求：需求工程师需要具备技能要求：（1）计算机专业技能）计算机专业技能（2）沟通能力）沟通能力（3）协调能力）协调能力（4）文档编写能力）文档编写能力（5）创新能力）创新能力第一章本章结 束2.1 需求获取的基本概念2016 软件需求获取，英
27、文全称软件需求获取，英文全称SoftwareRequirementElicitation，是软件需求工，是软件需求工程中最前沿部分，是软件设计的第一个程中最前沿部分，是软件设计的第一个阶段，其本质主要是人的活动，主要涉阶段，其本质主要是人的活动，主要涉及软件需求工程师如何与客户建立有效及软件需求工程师如何与客户建立有效沟通，是从需求来源获取需求的技术，沟通，是从需求来源获取需求的技术，是一个确定和理解不同用户类的需要和是一个确定和理解不同用户类的需要和限制的过程。故软件需求获取也可称限制的过程。故软件需求获取也可称“软件需求发现软件需求发现”、“软件需求获得软件需求获得”。1.1.1.1.什么
28、是软件需求获取什么是软件需求获取什么是软件需求获取什么是软件需求获取软件需求获取软件需求获取软件需求获取软件需求获取1)1)软件需求工程包括需求获取，需求软件需求工程包括需求获取，需求分析，编写需求规格说明文档，需求分析，编写需求规格说明文档，需求验证，需求管理。验证，需求管理。2)2)软件开发时，需求获取是最关键的软件开发时，需求获取是最关键的环节。环节。3)3)软件需求获取是软件需求工程的主软件需求获取是软件需求工程的主体。体。4)4)软件需求获取可能是软件开发过程软件需求获取可能是软件开发过程中最困难、最关键、最易出错及最需中最困难、最关键、最易出错及最需要交流的阶段。要交流的阶段。5)
29、5)软件需求获取是软件需求工程的主软件需求获取是软件需求工程的主体。体。6)6)软件需求获取可能是软件开发过程软件需求获取可能是软件开发过程中最困难、最关键、最易出错及最需中最困难、最关键、最易出错及最需要交流的阶段。要交流的阶段。 2 2. .软件需求获取在需求工程中的地位软件需求获取在需求工程中的地位软件需求获取软件需求获取软件需求获取软件需求获取前景和范围文档前景和范围文档需求获取最终形成相关需求获取最终形成相关资料的记录和保存，产资料的记录和保存，产生需求获取报告。生需求获取报告。需求工程过程一般主要需求工程过程一般主要产生三份文档：产生三份文档：前景和范围文档，前景和范围文档，用例说
30、明文档（假设需用例说明文档（假设需求分析时采用面向对象求分析时采用面向对象分析法），分析法），软件需求规格说明文档。软件需求规格说明文档。 3 3 3 3 . . . .需求获取需求获取需求获取需求获取结果结果结果结果软件需求获取软件需求获取软件需求获取软件需求获取用例说明文档用例说明文档用例说明文档用例说明文档软件需求规格说软件需求规格说软件需求规格说软件需求规格说明文档明文档明文档明文档感谢聆 听20162.2 需求获取过程2016需求需求需求需求本身本身本身本身业务业务业务业务描述描述描述描述环境和环境和环境和环境和约束约束约束约束确定获取需求的内容确定获取需求的内容软件需求获取软件需求
31、获取软件需求获取软件需求获取需求获取要获取的信息内容包括三大类：需求获取要获取的信息内容包括三大类：需求获取要获取的信息内容包括三大类：需求获取要获取的信息内容包括三大类：需求本身需求本身需求本身需求本身 业务描述业务描述业务描述业务描述 环境和约束环境和约束环境和约束环境和约束涉众涉众相关产品相关产品硬数据硬数据重要文档重要文档软件需求获取相关技术相关技术标准和法标准和法规规非传统方法非传统方法非传统方法非传统方法传统方法传统方法传统方法传统方法1.面谈法面谈法2.原型法原型法3.模型驱动法模型驱动法4.基于上下文的基于上下文的方法方法5.认知方法认知方法基于知识的方法，基于知识的方法，基于
32、观点的方法基于观点的方法软件需求获取确定获取需求的方法确定获取需求的方法执行获取执行获取 选择采用适当的需求获取方法和技术，执行获取过程。在需求获取过程中将产生以各种形式记在需求获取过程中将产生以各种形式记在需求获取过程中将产生以各种形式记在需求获取过程中将产生以各种形式记录的需求获取资料，包括文字、文档、录的需求获取资料，包括文字、文档、录的需求获取资料，包括文字、文档、录的需求获取资料，包括文字、文档、调研卷、报告、录音、视频等不同的记调研卷、报告、录音、视频等不同的记调研卷、报告、录音、视频等不同的记调研卷、报告、录音、视频等不同的记录和原始资料，需求获取方应将这些记录和原始资料，需求获
33、取方应将这些记录和原始资料，需求获取方应将这些记录和原始资料，需求获取方应将这些记录纳入开发库进行配置管理，并且整理录纳入开发库进行配置管理，并且整理录纳入开发库进行配置管理，并且整理录纳入开发库进行配置管理，并且整理生成项目的原始需求文档。需求获取的生成项目的原始需求文档。需求获取的生成项目的原始需求文档。需求获取的生成项目的原始需求文档。需求获取的记录与资料包括但不限于用户访谈的访记录与资料包括但不限于用户访谈的访记录与资料包括但不限于用户访谈的访记录与资料包括但不限于用户访谈的访谈纪要，面谈报告，需求研讨会的会议谈纪要，面谈报告，需求研讨会的会议谈纪要，面谈报告，需求研讨会的会议谈纪要，
34、面谈报告，需求研讨会的会议纪要，相关的政策法规文件，业务规则纪要，相关的政策法规文件，业务规则纪要，相关的政策法规文件，业务规则纪要，相关的政策法规文件，业务规则文件以及行业标准文件，需求原型，用文件以及行业标准文件，需求原型，用文件以及行业标准文件，需求原型，用文件以及行业标准文件，需求原型，用例列表文档。例列表文档。例列表文档。例列表文档。 需求获取成果整理和分析后，需求获取成果整理和分析后，需求获取成果整理和分析后，需求获取成果整理和分析后，将最终形成前景和范围文档、用例说明将最终形成前景和范围文档、用例说明将最终形成前景和范围文档、用例说明将最终形成前景和范围文档、用例说明文档。文档。
35、文档。文档。 需求获取活动过程需求获取活动过程软件需求获取感谢聆 听20162.3 业务需求业务需求业务需求业务需求业务需求在一个项目开始的时候（发现问题），在一个项目开始的时候（发现问题），在一个项目开始的时候（发现问题），在一个项目开始的时候（发现问题），要考虑（分析问题）要考虑（分析问题）要考虑（分析问题）要考虑（分析问题）为什么要启为什么要启为什么要启为什么要启动该项目？意思就是项目的目标是什动该项目？意思就是项目的目标是什动该项目？意思就是项目的目标是什动该项目？意思就是项目的目标是什么。么。么。么。 项目的目标就是系统的业务需求。项目的目标就是系统的业务需求。项目的目标就是系统的业
36、务需求。项目的目标就是系统的业务需求。 前景（前景（前景（前景（visionvision），就是描述产品的作），就是描述产品的作），就是描述产品的作），就是描述产品的作用，最终的功能。通过业务需求可定用，最终的功能。通过业务需求可定用，最终的功能。通过业务需求可定用，最终的功能。通过业务需求可定义前景。业务需求决定了前景的广度义前景。业务需求决定了前景的广度义前景。业务需求决定了前景的广度义前景。业务需求决定了前景的广度和深度。和深度。和深度。和深度。 前景把项目参与者定位到一前景把项目参与者定位到一前景把项目参与者定位到一前景把项目参与者定位到一个共同和明确的方向上。个共同和明确的方向上。个
37、共同和明确的方向上。个共同和明确的方向上。1 1 1 1业务需求业务需求业务需求业务需求案例分析：案例分析：案例分析：案例分析：“Android“Android“Android“Android点餐系统点餐系统点餐系统点餐系统”的业务需求从应用背景、业务的业务需求从应用背景、业务的业务需求从应用背景、业务的业务需求从应用背景、业务机遇、业务目标、业务风险、获取问题、明确问题六机遇、业务目标、业务风险、获取问题、明确问题六机遇、业务目标、业务风险、获取问题、明确问题六机遇、业务目标、业务风险、获取问题、明确问题六个方面进行介绍，我们来看具体描述：个方面进行介绍，我们来看具体描述：个方面进行介绍，我
38、们来看具体描述：个方面进行介绍，我们来看具体描述：业务需求1 1 1 1业务需求业务需求业务需求业务需求案例分析：案例分析：案例分析：案例分析：1.1.1.1.业务需求业务需求业务需求业务需求1.11.11.11.1应用背景应用背景应用背景应用背景M M M M餐厅由于有特色，菜品丰富等优点，名气越来越大，而店面餐厅由于有特色，菜品丰富等优点，名气越来越大，而店面餐厅由于有特色，菜品丰富等优点，名气越来越大，而店面餐厅由于有特色，菜品丰富等优点，名气越来越大，而店面规模有限，出现了餐饮高峰时期顾客人满为患的情况，大批规模有限，出现了餐饮高峰时期顾客人满为患的情况，大批规模有限，出现了餐饮高峰时
39、期顾客人满为患的情况，大批规模有限，出现了餐饮高峰时期顾客人满为患的情况，大批顾客因排队时间过程而产生不满情绪或直接离开。餐厅经营顾客因排队时间过程而产生不满情绪或直接离开。餐厅经营顾客因排队时间过程而产生不满情绪或直接离开。餐厅经营顾客因排队时间过程而产生不满情绪或直接离开。餐厅经营者为了在扩充店面尚未完成的情况下，尽可能增加顾客好感者为了在扩充店面尚未完成的情况下，尽可能增加顾客好感者为了在扩充店面尚未完成的情况下，尽可能增加顾客好感者为了在扩充店面尚未完成的情况下，尽可能增加顾客好感度，防止新老客户流失，想要一个餐厅专属度，防止新老客户流失，想要一个餐厅专属度，防止新老客户流失，想要一个
40、餐厅专属度，防止新老客户流失，想要一个餐厅专属APPAPPAPPAPP，用来向顾客，用来向顾客，用来向顾客，用来向顾客提供餐厅信息，和一些预约订餐功能，节约顾客的等候时间，提供餐厅信息，和一些预约订餐功能，节约顾客的等候时间，提供餐厅信息，和一些预约订餐功能，节约顾客的等候时间，提供餐厅信息，和一些预约订餐功能，节约顾客的等候时间，增加顾客的满意度，减少顾客排队困扰，提升餐厅的名气。增加顾客的满意度，减少顾客排队困扰，提升餐厅的名气。增加顾客的满意度，减少顾客排队困扰，提升餐厅的名气。增加顾客的满意度，减少顾客排队困扰，提升餐厅的名气。期望在系统上线期望在系统上线期望在系统上线期望在系统上线2
41、 2 2 2个月后，每周的餐厅客流量提高个月后，每周的餐厅客流量提高个月后，每周的餐厅客流量提高个月后，每周的餐厅客流量提高10%10%10%10%，顾客，顾客，顾客，顾客好评度增加好评度增加好评度增加好评度增加5%5%5%5%（餐厅通过调查统计好评度），顾客流失率减（餐厅通过调查统计好评度），顾客流失率减（餐厅通过调查统计好评度），顾客流失率减（餐厅通过调查统计好评度），顾客流失率减少少少少10%10%10%10%（餐厅通过排队取号作废数量来统计顾客流失情况，流（餐厅通过排队取号作废数量来统计顾客流失情况，流（餐厅通过排队取号作废数量来统计顾客流失情况，流（餐厅通过排队取号作废数量来统计顾客
42、流失情况，流失率为：离开顾客失率为：离开顾客失率为：离开顾客失率为：离开顾客/ / / /（用餐顾客（用餐顾客（用餐顾客（用餐顾客+ + + +离开顾客）。离开顾客）。离开顾客）。离开顾客）。业务需求1 1 1 1业务需求业务需求业务需求业务需求案例分析：案例分析：案例分析：案例分析：1.1.1.1.业务需求业务需求业务需求业务需求1.21.21.21.2业务机遇业务机遇业务机遇业务机遇M M M M餐厅店面规模有限，在扩充店面尚未完成的情况下，大批顾餐厅店面规模有限，在扩充店面尚未完成的情况下，大批顾餐厅店面规模有限，在扩充店面尚未完成的情况下，大批顾餐厅店面规模有限，在扩充店面尚未完成的情
43、况下，大批顾客因为排队时间过长直接离开，如果上线一款可以提供餐厅客因为排队时间过长直接离开，如果上线一款可以提供餐厅客因为排队时间过长直接离开，如果上线一款可以提供餐厅客因为排队时间过长直接离开，如果上线一款可以提供餐厅信息、等待时间、线上订餐的信息、等待时间、线上订餐的信息、等待时间、线上订餐的信息、等待时间、线上订餐的APPAPPAPPAPP可以显著改善等待顾客的人可以显著改善等待顾客的人可以显著改善等待顾客的人可以显著改善等待顾客的人数，提高餐厅的营业额，减少顾客对餐厅的差评率。通过推数，提高餐厅的营业额，减少顾客对餐厅的差评率。通过推数，提高餐厅的营业额，减少顾客对餐厅的差评率。通过推
44、数，提高餐厅的营业额，减少顾客对餐厅的差评率。通过推送新菜品还可以起到良好的宣传效果，吸引更多的顾客，营送新菜品还可以起到良好的宣传效果，吸引更多的顾客，营送新菜品还可以起到良好的宣传效果，吸引更多的顾客，营送新菜品还可以起到良好的宣传效果，吸引更多的顾客，营造良好的口碑。造良好的口碑。造良好的口碑。造良好的口碑。业务需求1 1 1 1业务需求。业务需求。业务需求。业务需求。案例分析：案例分析：案例分析：案例分析：1.31.31.31.3业务目标业务目标业务目标业务目标BO-1BO-1BO-1BO-1：在系统使用：在系统使用：在系统使用：在系统使用2 2 2 2个月个月个月个月后，每周餐厅客流
45、量提高后，每周餐厅客流量提高后，每周餐厅客流量提高后，每周餐厅客流量提高度量标准（度量标准（度量标准（度量标准（ScaleScaleScaleScale）：客）：客）：客）：客流量流量流量流量计量方法：餐厅通过订单计量方法：餐厅通过订单计量方法：餐厅通过订单计量方法：餐厅通过订单上座率来计算客流量上座率来计算客流量上座率来计算客流量上座率来计算客流量理想标准：提高理想标准：提高理想标准：提高理想标准：提高30%30%30%30%一般标准：提高一般标准：提高一般标准：提高一般标准：提高20%20%20%20%最低标准：提高最低标准：提高最低标准：提高最低标准：提高10%10%10%10%BO-2
46、BO-2BO-2BO-2：在系统使用：在系统使用：在系统使用：在系统使用2 2 2 2个月个月个月个月后，顾客好评度增加后，顾客好评度增加后，顾客好评度增加后，顾客好评度增加度量标准（度量标准（度量标准（度量标准（ScaleScaleScaleScale）：顾）：顾）：顾）：顾客好评度客好评度客好评度客好评度计量方法：餐厅通过问卷计量方法：餐厅通过问卷计量方法：餐厅通过问卷计量方法：餐厅通过问卷调查以及线上评价来统计调查以及线上评价来统计调查以及线上评价来统计调查以及线上评价来统计好评度好评度好评度好评度理想标准：增加理想标准：增加理想标准：增加理想标准：增加20%20%20%20%一般标准：
47、增加一般标准：增加一般标准：增加一般标准：增加10%10%10%10%最低标准：增加最低标准：增加最低标准：增加最低标准：增加5%5%5%5%010302BO-3BO-3BO-3BO-3：在系统使用：在系统使用：在系统使用：在系统使用2 2 2 2个月后，个月后，个月后，个月后，顾客流失率减少顾客流失率减少顾客流失率减少顾客流失率减少度量标准（度量标准（度量标准（度量标准（ScaleScaleScaleScale）：顾客）：顾客）：顾客）：顾客流失情况流失情况流失情况流失情况计量方法：餐厅通过排队取计量方法：餐厅通过排队取计量方法：餐厅通过排队取计量方法：餐厅通过排队取号作废数量来统计顾客流失
48、号作废数量来统计顾客流失号作废数量来统计顾客流失号作废数量来统计顾客流失情况，流失率为：离开顾客情况，流失率为：离开顾客情况，流失率为：离开顾客情况，流失率为：离开顾客/ / / /（用餐顾客（用餐顾客（用餐顾客（用餐顾客+ + + +离开顾客）离开顾客）离开顾客）离开顾客）理想标准：减少理想标准：减少理想标准：减少理想标准：减少30%30%30%30%一般标准：减少一般标准：减少一般标准：减少一般标准：减少20%20%20%20%最低标准：减少最低标准：减少最低标准：减少最低标准：减少10%10%10%10%业务需求1 1 1 1业务需求。业务需求。业务需求。业务需求。案例分析：案例分析：案
49、例分析：案例分析：1.31.31.31.3业务目标业务目标业务目标业务目标BO-4BO-4BO-4BO-4：在系统使用：在系统使用：在系统使用：在系统使用2 2 2 2个月个月个月个月后，餐厅门口的顾客等待后，餐厅门口的顾客等待后，餐厅门口的顾客等待后，餐厅门口的顾客等待人数减少人数减少人数减少人数减少度量标准（度量标准（度量标准（度量标准（ScaleScaleScaleScale）：顾）：顾）：顾）：顾客等待人数客等待人数客等待人数客等待人数计量方法：通过取号顾客计量方法：通过取号顾客计量方法：通过取号顾客计量方法：通过取号顾客人数来统计等待人数人数来统计等待人数人数来统计等待人数人数来统计
50、等待人数理想标准：减少理想标准：减少理想标准：减少理想标准：减少50%50%50%50%一般标准：减少一般标准：减少一般标准：减少一般标准：减少30%30%30%30%最低标准：减少最低标准：减少最低标准：减少最低标准：减少20%20%20%20%010302BO-5BO-5BO-5BO-5：在系统使用：在系统使用：在系统使用：在系统使用6 6 6 6个月后，个月后，个月后，个月后，餐厅营业额提升餐厅营业额提升餐厅营业额提升餐厅营业额提升度量标准（度量标准（度量标准（度量标准（ScaleScaleScaleScale）：营业）：营业）：营业）：营业额额额额计量方法：通过系统统计报计量方法：通过
51、系统统计报计量方法：通过系统统计报计量方法：通过系统统计报表来计算表来计算表来计算表来计算 理想标准：提升理想标准：提升理想标准：提升理想标准：提升30%30%30%30%一般标准：提升一般标准：提升一般标准：提升一般标准：提升20%20%20%20%最低标准：提升最低标准：提升最低标准：提升最低标准：提升10%10%10%10%业务需求1.41.41.41.4业务风险业务风险业务风险业务风险RI-1RI-1RI-1RI-1：愿意使用该系统的顾客太少，减少了：愿意使用该系统的顾客太少，减少了：愿意使用该系统的顾客太少，减少了：愿意使用该系统的顾客太少，减少了对系统开发和变更餐厅经营过程的投资回
52、报，对系统开发和变更餐厅经营过程的投资回报，对系统开发和变更餐厅经营过程的投资回报，对系统开发和变更餐厅经营过程的投资回报，可能性可能性可能性可能性0.30.30.30.3，影响为，影响为，影响为，影响为9 9 9 9RI-2RI-2RI-2RI-2：增加了线上订单，需要更新财务部门计算系统软：增加了线上订单，需要更新财务部门计算系统软：增加了线上订单，需要更新财务部门计算系统软：增加了线上订单，需要更新财务部门计算系统软件，可能性件，可能性件，可能性件，可能性1 1 1 1，影响为，影响为，影响为，影响为2 2 2 2AddupyourtextAddupyourtextAddupyourte
53、xt业务风险ADDYOURTEXTHERE1.51.51.51.5获取问题获取问题获取问题获取问题P1P1P1P1店面规模有限，高峰期顾客人满为患店面规模有限，高峰期顾客人满为患店面规模有限，高峰期顾客人满为患店面规模有限，高峰期顾客人满为患P2P2P2P2排队时间过长导致客源流失排队时间过长导致客源流失排队时间过长导致客源流失排队时间过长导致客源流失AddupyourtextAddupyourtextAddupyourtext获取问题ADDYOURTEXTHERE要素内容IDP1提出者餐厅经营者关联者餐厅投资者，总经理问题店面规模有限，高峰期顾客人满为患影响顾客排队时间过长部分顾客放弃等待离
54、开顾客就餐氛围差、环境嘈杂餐厅门口等待人数过多影响店面形象长此以往影响餐厅口碑流失潜在顾客1 1 1 1业务需求业务需求业务需求业务需求案例分析：案例分析：案例分析：案例分析：1.61.6明确问题明确问题明确问题明确问题业务需求业务需求要素内容IDP2提出者负责接待的服务生关联者餐厅经营者，总经理，大堂经理问题排队时间过长导致客源流失影响顾客满意度下降部分顾客放弃等待导致餐厅营业额下降餐厅门口等待人数众多影响门面和交通长此以往影响餐厅口碑流失潜在顾客1 1 1 1业务需求业务需求业务需求业务需求案例分析：案例分析：案例分析：案例分析：1.61.6明确问题明确问题明确问题明确问题感谢聆 听201
55、6系统边界201643%52%36%系统边界确定项目的范围对发现的问题进行分析后，对发现的问题进行分析后，对发现的问题进行分析后，对发现的问题进行分析后，确定问题，根据问题可以确定问题，根据问题可以确定问题，根据问题可以确定问题，根据问题可以确定系统的高层次解决方确定系统的高层次解决方确定系统的高层次解决方确定系统的高层次解决方案和系统特性，回答案和系统特性，回答案和系统特性，回答案和系统特性，回答项目打算做什么？项目打算做什么？项目打算做什么？项目打算做什么？ 即回答系统的功能有即回答系统的功能有即回答系统的功能有即回答系统的功能有什么，并描述系统的边界，什么，并描述系统的边界，什么，并描述
56、系统的边界，什么，并描述系统的边界，即哪些功能是在系统内，即哪些功能是在系统内，即哪些功能是在系统内，即哪些功能是在系统内，哪些功能在系统外。哪些功能在系统外。哪些功能在系统外。哪些功能在系统外。 范围（范围（范围（范围（scopescopescopescope），就是），就是），就是），就是边界。边界。边界。边界。系统的功能和边界的描述有两种：系统的功能和边界的描述有两种：系统的功能和边界的描述有两种：系统的功能和边界的描述有两种：（1 1 1 1）上下文图）上下文图）上下文图）上下文图 系统上下文图，也称系统关联图。系统上下文图，也称系统关联图。系统上下文图，也称系统关联图。系统上下文图，
57、也称系统关联图。对系统范围的描述确立了正在开发的系对系统范围的描述确立了正在开发的系对系统范围的描述确立了正在开发的系对系统范围的描述确立了正在开发的系统与周围事物之间的界线和联系，系统统与周围事物之间的界线和联系，系统统与周围事物之间的界线和联系，系统统与周围事物之间的界线和联系，系统上下文图用图形方式说明了这一界线。上下文图用图形方式说明了这一界线。上下文图用图形方式说明了这一界线。上下文图用图形方式说明了这一界线。 例如：例如：例如：例如：AndroidAndroidAndroidAndroid点餐系统的上下文图点餐系统的上下文图点餐系统的上下文图点餐系统的上下文图 例如：例如：例如：例
58、如：AndroidAndroidAndroidAndroid点餐系统的用例图点餐系统的用例图点餐系统的用例图点餐系统的用例图 系统边界确定项目的范围主要特性与功能主要特性与功能主要特性与功能主要特性与功能SF1SF1SF1SF1：提供餐厅菜品信息（价格、评分、：提供餐厅菜品信息（价格、评分、：提供餐厅菜品信息（价格、评分、：提供餐厅菜品信息（价格、评分、评价等）和当天热门菜品评价等）和当天热门菜品评价等）和当天热门菜品评价等）和当天热门菜品SF2SF2SF2SF2：提供在线预约、取号、下单、支：提供在线预约、取号、下单、支：提供在线预约、取号、下单、支：提供在线预约、取号、下单、支付功能付功能
59、付功能付功能SF3SF3SF3SF3：推送餐厅新菜品和促销优惠信息：推送餐厅新菜品和促销优惠信息：推送餐厅新菜品和促销优惠信息：推送餐厅新菜品和促销优惠信息SF4SF4SF4SF4：记录顾客订单信息和基本信息：记录顾客订单信息和基本信息：记录顾客订单信息和基本信息：记录顾客订单信息和基本信息SF5SF5SF5SF5：系统短信通知顾客是否可以去往：系统短信通知顾客是否可以去往：系统短信通知顾客是否可以去往：系统短信通知顾客是否可以去往餐厅就餐餐厅就餐餐厅就餐餐厅就餐SF6SF6SF6SF6：顾客可以对已定菜品进行打分和：顾客可以对已定菜品进行打分和：顾客可以对已定菜品进行打分和：顾客可以对已定菜
60、品进行打分和评价评价评价评价感谢聆 听20162.5 前景和范围文档的编写2016业务需求、系统高层次解决方案和系统特性都可被定义到系统前景和范围文档中。系统前景和范围文档由软件需求工程师完成，但文档的负责人一般是项目的投资负责人、执行主管或类似角色。文档的审核、确认以及所有权归项目的投资负责人、执行主管或其他类似角色。前景和范围文档的编写1 业务需求1.1 应用背景1.2 业务机遇1.3 业务目标1.4 业务风险2 项目前景2.1 前景概述2.2 功能特性2.3 假设与依赖3 项目范围3.1 第一版本范围前景和范围文档的编写3.2 后续版本范围3.3 限制与排除4 项目环境4.1 操作环境4
61、.2 涉众4.3 项目属性 词汇表参考资料附录文文档档格格式式前景和范围文档的编写2.前景与范围文档写作范例前景与范围文档写作范例结合下面前景与范围文档案结合下面前景与范围文档案例，进行相关项描述说明：例，进行相关项描述说明：（2）“Android点餐系统点餐系统”的的前景和范围文档前景和范围文档请参考本请参考本节文档：节文档：感谢聆 听20162.6 涉众与硬数据20161.1.什么是涉众什么是涉众与系统目标相关的人和物，英文称与系统目标相关的人和物，英文称为为Stakeholder，即涉众或项目干，即涉众或项目干系人。系人。涉众与硬数据涉众与硬数据1.1.什么是涉众什么是涉众项目涉众包括：
62、项目涉众包括：客户：为达到其公司的业务目标而投资项目客户：为达到其公司的业务目标而投资项目或购买产品。或购买产品。用户：直接或间接与产品打交道，是客户的用户：直接或间接与产品打交道，是客户的一部分。一部分。需求分析员：负责编写需求并传达给开发团需求分析员：负责编写需求并传达给开发团队。队。开发人员：设计、实现和维护产品。开发人员：设计、实现和维护产品。测试人员：确定产品的行为是否与预计的相测试人员：确定产品的行为是否与预计的相一致。一致。文档编制人员：负责编写用户手册、培训资文档编制人员：负责编写用户手册、培训资料和系统帮助。料和系统帮助。项目经理：制定项目计划并带领开发人员获项目经理：制定项
63、目计划并带领开发人员获得成功。得成功。法律人员：确保产品符合所有相关法规。法律人员：确保产品符合所有相关法规。生产人员：制造包含该软件的产品。生产人员：制造包含该软件的产品。市场营销、技术支持及其他与产品和客户打市场营销、技术支持及其他与产品和客户打交道的人员。交道的人员。涉众与硬数据2渉众分析渉众分析涉众分析包括：涉众分析包括：涉众识别，涉众识别，涉众识别，涉众识别，涉众描述，涉众描述，涉众描述，涉众描述，涉众列表，涉众列表，涉众列表，涉众列表，涉众扩展特性描述，涉众扩展特性描述，涉众扩展特性描述，涉众扩展特性描述，涉众评估，涉众评估，涉众评估，涉众评估，涉众选择。涉众选择。涉众选择。涉众选
64、择。涉众与硬数据2渉众分析渉众分析（1 1）涉众识别）涉众识别）涉众识别）涉众识别:涉众识别的基本过程：涉众识别的基本过程：涉众识别的基本过程：涉众识别的基本过程：第一步，第一步，第一步，第一步， 集中初始涉众，进行集体讨论，例集中初始涉众，进行集体讨论，例集中初始涉众，进行集体讨论，例集中初始涉众，进行集体讨论，例如头脑风暴等，尽可能列数涉众类别列表。如头脑风暴等，尽可能列数涉众类别列表。如头脑风暴等，尽可能列数涉众类别列表。如头脑风暴等，尽可能列数涉众类别列表。列举涉众类别列表，要注意使用代表其特征列举涉众类别列表，要注意使用代表其特征列举涉众类别列表，要注意使用代表其特征列举涉众类别列表
65、，要注意使用代表其特征的名称，以细化涉众。的名称，以细化涉众。的名称，以细化涉众。的名称，以细化涉众。 第二步，第二步，第二步，第二步， 对涉众类别列表进行分析，根据与对涉众类别列表进行分析，根据与对涉众类别列表进行分析，根据与对涉众类别列表进行分析，根据与系统的相关性，找出关键涉众类别，形成关系统的相关性，找出关键涉众类别，形成关系统的相关性，找出关键涉众类别，形成关系统的相关性，找出关键涉众类别，形成关键涉众类别列表。可以将涉众类别建立成网键涉众类别列表。可以将涉众类别建立成网键涉众类别列表。可以将涉众类别建立成网键涉众类别列表。可以将涉众类别建立成网络，来表示涉众类别间的交互。网络图可以
66、络，来表示涉众类别间的交互。网络图可以络，来表示涉众类别间的交互。网络图可以络，来表示涉众类别间的交互。网络图可以直观显示涉众的关键性。直观显示涉众的关键性。直观显示涉众的关键性。直观显示涉众的关键性。涉众与硬数据2渉众分析渉众分析（1 1）涉众识别）涉众识别）涉众识别）涉众识别:涉众识别的基涉众识别的基涉众识别的基涉众识别的基本过程：本过程：本过程：本过程： 第二步，从关键涉众类别列表中选第二步，从关键涉众类别列表中选第二步，从关键涉众类别列表中选第二步，从关键涉众类别列表中选择代表，继续集体讨论，例如头脑风择代表，继续集体讨论，例如头脑风择代表，继续集体讨论，例如头脑风择代表，继续集体讨论
67、，例如头脑风暴，列出新的涉众类别列表。如果和暴，列出新的涉众类别列表。如果和暴，列出新的涉众类别列表。如果和暴，列出新的涉众类别列表。如果和第一步产生涉众类别列表相差不大，第一步产生涉众类别列表相差不大，第一步产生涉众类别列表相差不大，第一步产生涉众类别列表相差不大，则可以结束涉众识别。否则继续进行则可以结束涉众识别。否则继续进行则可以结束涉众识别。否则继续进行则可以结束涉众识别。否则继续进行上述第二步。上述第二步。上述第二步。上述第二步。涉众识别涉众识别涉众识别涉众识别:androidandroid点餐系统的涉众识别点餐系统的涉众识别点餐系统的涉众识别点餐系统的涉众识别首先，显而易见的初始涉
68、众有餐厅经营者和顾客，首先，显而易见的初始涉众有餐厅经营者和顾客，首先，显而易见的初始涉众有餐厅经营者和顾客，首先，显而易见的初始涉众有餐厅经营者和顾客，故而我们选出一名顾客代表，并与餐厅经营者代表故而我们选出一名顾客代表，并与餐厅经营者代表故而我们选出一名顾客代表，并与餐厅经营者代表故而我们选出一名顾客代表，并与餐厅经营者代表进行讨论。进行讨论。进行讨论。进行讨论。通过讨论得出以下结论：通过讨论得出以下结论：通过讨论得出以下结论：通过讨论得出以下结论：餐厅经营者使用本系统时，安排服务员工作，餐厅经营者使用本系统时，安排服务员工作，餐厅经营者使用本系统时，安排服务员工作，餐厅经营者使用本系统时
69、，安排服务员工作，额外涉众有服务员。额外涉众有服务员。额外涉众有服务员。额外涉众有服务员。系统支持在线支付功能，额外涉众有收银员和系统支持在线支付功能，额外涉众有收银员和系统支持在线支付功能，额外涉众有收银员和系统支持在线支付功能，额外涉众有收银员和在线支付平台。在线支付平台。在线支付平台。在线支付平台。系统允许顾客在线预约并点菜，额外涉众有厨系统允许顾客在线预约并点菜，额外涉众有厨系统允许顾客在线预约并点菜，额外涉众有厨系统允许顾客在线预约并点菜，额外涉众有厨师。师。师。师。客户使用本系统，需要有移动终端设备并且消客户使用本系统，需要有移动终端设备并且消客户使用本系统，需要有移动终端设备并且
70、消客户使用本系统，需要有移动终端设备并且消耗一定流量或使用耗一定流量或使用耗一定流量或使用耗一定流量或使用wifiwifi，额外涉众有移动终端设备，额外涉众有移动终端设备，额外涉众有移动终端设备，额外涉众有移动终端设备销售商和通信运营商。销售商和通信运营商。销售商和通信运营商。销售商和通信运营商。通过分析，关键涉众有餐厅经营者、服务员、收银通过分析，关键涉众有餐厅经营者、服务员、收银通过分析，关键涉众有餐厅经营者、服务员、收银通过分析，关键涉众有餐厅经营者、服务员、收银员、厨师、顾客。员、厨师、顾客。员、厨师、顾客。员、厨师、顾客。他们之间的关系如图所示。他们之间的关系如图所示。他们之间的关系
71、如图所示。他们之间的关系如图所示。 涉众与硬数据渉众分析渉众分析渉众分析（2 2）涉众描述，涉众）涉众描述，涉众）涉众描述，涉众）涉众描述，涉众列表，涉众扩展特性描列表，涉众扩展特性描列表，涉众扩展特性描列表，涉众扩展特性描述述述述 涉众描述首先描述涉众描述首先描述涉众描述首先描述涉众描述首先描述涉众的基本特征，包括涉众的基本特征，包括涉众的基本特征，包括涉众的基本特征，包括个人特征和工作特征，个人特征和工作特征，个人特征和工作特征，个人特征和工作特征，有时也需要描述涉众的有时也需要描述涉众的有时也需要描述涉众的有时也需要描述涉众的地理和社会特征。地理和社会特征。地理和社会特征。地理和社会特征
72、。涉众列表涉众列表涉众列表涉众列表 将所有涉众罗列出来。将所有涉众罗列出来。将所有涉众罗列出来。将所有涉众罗列出来。涉众扩展特性描述涉众扩展特性描述涉众扩展特性描述涉众扩展特性描述 还有一些扩展的涉众信息，还有一些扩展的涉众信息，还有一些扩展的涉众信息，还有一些扩展的涉众信息，比较重要，需要描述，包括对比较重要，需要描述，包括对比较重要，需要描述，包括对比较重要，需要描述，包括对项目的关注点、兴趣，是反对项目的关注点、兴趣，是反对项目的关注点、兴趣，是反对项目的关注点、兴趣，是反对还是赞同，会不会影响项目进还是赞同，会不会影响项目进还是赞同，会不会影响项目进还是赞同，会不会影响项目进程等。对项
73、目的期望，往往也程等。对项目的期望，往往也程等。对项目的期望，往往也程等。对项目的期望，往往也决定项目是否成功。项目可能决定项目是否成功。项目可能决定项目是否成功。项目可能决定项目是否成功。项目可能受到的影响，可以描述为具体受到的影响，可以描述为具体受到的影响，可以描述为具体受到的影响，可以描述为具体内容及影响程度。可能受到外内容及影响程度。可能受到外内容及影响程度。可能受到外内容及影响程度。可能受到外来项目的影响，可以描述为影来项目的影响，可以描述为影来项目的影响，可以描述为影来项目的影响，可以描述为影响内容和影响强度。响内容和影响强度。响内容和影响强度。响内容和影响强度。 涉众与硬数据涉众
74、与硬数据2渉众分析渉众分析（2 2 2 2）涉众描述，涉众列）涉众描述，涉众列）涉众描述，涉众列）涉众描述，涉众列表，涉众扩展特性描述表，涉众扩展特性描述表，涉众扩展特性描述表，涉众扩展特性描述 例如：例如：例如：例如：androidandroidandroidandroid点餐系统点餐系统点餐系统点餐系统的涉众描述：的涉众描述：的涉众描述：的涉众描述：通过分析，对于系统涉众通过分析，对于系统涉众通过分析，对于系统涉众通过分析，对于系统涉众的特征描述如右表所示的特征描述如右表所示的特征描述如右表所示的特征描述如右表所示涉众涉众基本特征基本特征餐厅餐厅经营经营者者餐厅经营者使用本系统来接受预约餐
75、厅经营者使用本系统来接受预约或排号，是本系统的主要使用者之或排号，是本系统的主要使用者之一。餐厅经营者需要在系统中提供一。餐厅经营者需要在系统中提供菜品目录，方便客户预约点菜。菜品目录，方便客户预约点菜。服务服务员员当餐厅经营者接受排号时，安排服当餐厅经营者接受排号时，安排服务员给前来的顾客提供服务。服务务员给前来的顾客提供服务。服务员并不直接使用本系统，服务员通员并不直接使用本系统，服务员通过餐厅经营者间接使用系统。过餐厅经营者间接使用系统。收银收银员员收银员使用本系统来接受顾客的在收银员使用本系统来接受顾客的在线支付行为。收银员允许顾客使用线支付行为。收银员允许顾客使用多种在线支付平台进行
76、支付。多种在线支付平台进行支付。厨师厨师当顾客预约点菜时，厨师提前做菜当顾客预约点菜时，厨师提前做菜上菜。厨师并不直接使用本系统，上菜。厨师并不直接使用本系统，厨师通过餐厅经营者间接使用系统。厨师通过餐厅经营者间接使用系统。顾客顾客顾客使用本系统来预约、排号、在顾客使用本系统来预约、排号、在线支付，是本系统的主要使用者之线支付，是本系统的主要使用者之一。一。涉众与硬数据2渉众分析渉众分析例如：例如：android点餐系统的涉众描述：点餐系统的涉众描述：通过分析，通过分析，对于系统涉众对于系统涉众的的扩展扩展特征描述如下表所示特征描述如下表所示涉众扩展特征主要目标态度主要关注点约束条件餐厅经营者
77、提高餐厅效率，提高用户满意度对本系统强烈支持提高用户的满意度餐厅需要有设备支持服务员 工作轻松支持不会提高工作量无收银员 工作更有效率支持工作更高效能够操控计算机厨师工作轻松无所谓 不会提高工作量无顾客更方便地享受服务支持更加便捷拥有相应设备涉众与硬数据涉众与硬数据涉众与硬数据（3 3 3 3）涉众评估）涉众评估）涉众评估）涉众评估涉众描述后，得到大量的涉众信息。对这些信息联合起来分析，涉众描述后，得到大量的涉众信息。对这些信息联合起来分析，涉众描述后，得到大量的涉众信息。对这些信息联合起来分析，涉众描述后，得到大量的涉众信息。对这些信息联合起来分析，得到更深层次的信息，就是涉众评估。得到更深
78、层次的信息，就是涉众评估。得到更深层次的信息，就是涉众评估。得到更深层次的信息，就是涉众评估。 涉众评估包括优先级评估，风险评估，共赢评估，涉众评估包括优先级评估，风险评估，共赢评估，涉众评估包括优先级评估，风险评估，共赢评估，涉众评估包括优先级评估，风险评估，共赢评估， 优先级评优先级评优先级评优先级评估估估估涉众与硬数据涉众与硬数据2渉众分析渉众分析(3)(3)涉众评估涉众评估涉众评估涉众评估案例案例案例案例再基于涉众的基本特征，再基于涉众的基本特征，再基于涉众的基本特征，再基于涉众的基本特征，建立建立建立建立User/TaskUser/Task矩阵，对矩阵，对矩阵，对矩阵，对矩阵内容分析
79、比较，评矩阵内容分析比较，评矩阵内容分析比较，评矩阵内容分析比较，评估涉众优先级：估涉众优先级：估涉众优先级：估涉众优先级：表表表表3 3涉众涉众涉众涉众User/TaskUser/Task矩阵矩阵矩阵矩阵用户群体任务群体数优先级餐厅经营者接受预约、摇号45服务员提供具体服务102收银员接受在线支付13厨师提前做菜 41顾客预约、摇号、在线支付大量42 2 2 2 涉众分析涉众分析涉众分析涉众分析（3 3）涉众评估）涉众评估）涉众评估）涉众评估案例案例案例案例风险评估风险评估风险评估风险评估分析涉众的态度，建立分析涉众的态度，建立分析涉众的态度，建立分析涉众的态度，建立Power/Attitu
80、dePower/Attitude分布图：分布图：分布图：分布图：涉众与硬数据2 2 2 2 涉众分析涉众分析涉众分析涉众分析（3 3）涉众评估）涉众评估）涉众评估）涉众评估案例案例案例案例风险评估风险评估风险评估风险评估分析涉众的态度，建立分析涉众的态度，建立分析涉众的态度，建立分析涉众的态度，建立Power/AttitudePower/AttitudePower/AttitudePower/Attitude分布图：分布图：分布图：分布图： 涉众涉众涉众涉众Power/AttitudePower/AttitudePower/AttitudePower/Attitude分布图分布图分布图分布图由
81、图可见，项目的风险主要来源由图可见，项目的风险主要来源由图可见，项目的风险主要来源由图可见，项目的风险主要来源于餐厅经营者和收银员，于餐厅经营者和收银员，于餐厅经营者和收银员，于餐厅经营者和收银员，但他们持支持的态度，所以项目但他们持支持的态度，所以项目但他们持支持的态度，所以项目但他们持支持的态度，所以项目风险风险风险风险不大，并不不大，并不不大，并不不大，并不需要特别考虑。需要特别考虑。需要特别考虑。需要特别考虑。涉众与硬数据2 2 2 2 涉众分析涉众分析涉众分析涉众分析（3 3）涉众评估）涉众评估）涉众评估）涉众评估案例案例案例案例共赢评估共赢评估共赢评估共赢评估建立建立建立建立Sta
82、keholder/IssueStakeholder/Issue关系图：关系图：关系图：关系图：涉众涉众涉众涉众Stakeholder/IssueStakeholder/Issue关系图关系图关系图关系图可以看出，在各个关系上，可以看出，在各个关系上，可以看出，在各个关系上，可以看出，在各个关系上，涉众的期望不会产生冲突，涉众的期望不会产生冲突，涉众的期望不会产生冲突，涉众的期望不会产生冲突，他们的期望与项目的业务需求他们的期望与项目的业务需求他们的期望与项目的业务需求他们的期望与项目的业务需求可以较为高度地保持一致，因可以较为高度地保持一致，因可以较为高度地保持一致，因可以较为高度地保持一致，
83、因此项目可以形成一个共赢的局此项目可以形成一个共赢的局此项目可以形成一个共赢的局此项目可以形成一个共赢的局面。面。面。面。涉众与硬数据涉众与硬数据2渉众分析渉众分析(3)(3)涉众评估涉众评估涉众评估涉众评估案例案例案例案例基于涉众的扩展特征，基于涉众的扩展特征，基于涉众的扩展特征，基于涉众的扩展特征，建立建立建立建立Power/InterestPower/Interest分布分布分布分布图：图：图：图：（4 4 4 4）涉众选择）涉众选择）涉众选择）涉众选择项目的成功在于很好地发现和理解关键涉众，项目的成功在于很好地发现和理解关键涉众，项目的成功在于很好地发现和理解关键涉众，项目的成功在于很
84、好地发现和理解关键涉众，并能使关键涉众在项目中起到关键作用。在对其角色和并能使关键涉众在项目中起到关键作用。在对其角色和并能使关键涉众在项目中起到关键作用。在对其角色和并能使关键涉众在项目中起到关键作用。在对其角色和职责定义后，可以为其选择代表，参与软件的开发过程。职责定义后，可以为其选择代表，参与软件的开发过程。职责定义后，可以为其选择代表，参与软件的开发过程。职责定义后，可以为其选择代表，参与软件的开发过程。或者寻找其替代源，使项目过程顺利。或者寻找其替代源，使项目过程顺利。或者寻找其替代源，使项目过程顺利。或者寻找其替代源，使项目过程顺利。AddupyourtextAddupyourte
85、xtAddupyourtext涉众与硬数据（5 5）涉众分析报告）涉众分析报告）涉众分析报告）涉众分析报告 一份完整的涉众分析报告包括涉众识别、一份完整的涉众分析报告包括涉众识别、一份完整的涉众分析报告包括涉众识别、一份完整的涉众分析报告包括涉众识别、涉众描述、涉众评估等。涉众描述、涉众评估等。涉众描述、涉众评估等。涉众描述、涉众评估等。AddupyourtextAddupyourtextAddupyourtext涉众与硬数据涉众与硬数据3 3硬数据硬数据硬数据硬数据定量硬数据：定量硬数据：定量硬数据：定量硬数据：（1 1）业务表格（）业务表格（）业务表格（）业务表格（2 2）统）统）统）统计
86、报表计报表计报表计报表定性硬数据：定性硬数据：定性硬数据：定性硬数据：（1 1）组织的描述文档）组织的描述文档）组织的描述文档）组织的描述文档（2 2）业务指导文档）业务指导文档）业务指导文档）业务指导文档（3 3）业务备忘录）业务备忘录）业务备忘录）业务备忘录涉众与硬数据3 3 3 3 硬数据硬数据硬数据硬数据分析下下面案例场景，回答问题。分析下下面案例场景，回答问题。分析下下面案例场景，回答问题。分析下下面案例场景，回答问题。“ “我知道你有很多材料。那些材料里到底有什么？我知道你有很多材料。那些材料里到底有什么？我知道你有很多材料。那些材料里到底有什么？我知道你有很多材料。那些材料里到底
87、有什么？” ”BettyKantBettyKant问道，她是问道，她是问道，她是问道，她是MISMIS特别特别特别特别工作组的负责人。工作组的负责人。工作组的负责人。工作组的负责人。MISMIS特别工作组是你的系统团队联络特别工作组是你的系统团队联络特别工作组是你的系统团队联络特别工作组是你的系统团队联络SawderSawder家具公司的桥梁。家具公司的桥梁。家具公司的桥梁。家具公司的桥梁。你拖了一大堆材料，正准备离开这栋楼。你拖了一大堆材料，正准备离开这栋楼。你拖了一大堆材料，正准备离开这栋楼。你拖了一大堆材料，正准备离开这栋楼。“ “哦，是过去哦，是过去哦，是过去哦，是过去6 6个月的一些
88、财政决算、生产报表，还有个月的一些财政决算、生产报表，还有个月的一些财政决算、生产报表，还有个月的一些财政决算、生产报表，还有SharonSharon给我的一些业绩报表，给我的一些业绩报表，给我的一些业绩报表，给我的一些业绩报表，业绩报表涵盖了过去业绩报表涵盖了过去业绩报表涵盖了过去业绩报表涵盖了过去6 6个月的目标和工作业绩。个月的目标和工作业绩。个月的目标和工作业绩。个月的目标和工作业绩。” ”你在回答时，有些纸掉到了地上，你在回答时，有些纸掉到了地上，你在回答时，有些纸掉到了地上，你在回答时，有些纸掉到了地上，“ “你为什么问这个问题呢？你为什么问这个问题呢？你为什么问这个问题呢？你为什
89、么问这个问题呢？” ”BettyBetty为你拾起纸并把它放到最近的桌子上，回答道：为你拾起纸并把它放到最近的桌子上，回答道：为你拾起纸并把它放到最近的桌子上，回答道：为你拾起纸并把它放到最近的桌子上，回答道：“ “因为你根本不需要这些垃因为你根本不需要这些垃因为你根本不需要这些垃因为你根本不需要这些垃圾。你来这里要做一件事情，就是和我们这些用户谈话。从这些材料中得不到任圾。你来这里要做一件事情，就是和我们这些用户谈话。从这些材料中得不到任圾。你来这里要做一件事情，就是和我们这些用户谈话。从这些材料中得不到任圾。你来这里要做一件事情，就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。何
90、有益的信息。何有益的信息。何有益的信息。” ”涉众与硬数据3 3 3 3 硬数据硬数据硬数据硬数据1.BettyKant1.BettyKant说说说说“ “因为你根本不需要这些垃圾。你来这里要做一件事情，因为你根本不需要这些垃圾。你来这里要做一件事情，因为你根本不需要这些垃圾。你来这里要做一件事情，因为你根本不需要这些垃圾。你来这里要做一件事情，就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。” ”你你你你认为认
91、为认为认为BettyKantBettyKant说的对吗？说的对吗？说的对吗？说的对吗？ 答：错答：错答：错答：错2.2.从场景片段中你能发现哪些硬数据？从场景片段中你能发现哪些硬数据？从场景片段中你能发现哪些硬数据？从场景片段中你能发现哪些硬数据？答：业务表格：财政决算答：业务表格：财政决算答：业务表格：财政决算答：业务表格：财政决算统计报表：生产报表，业绩报表统计报表：生产报表，业绩报表统计报表：生产报表，业绩报表统计报表：生产报表，业绩报表业务指导文档：业绩报表（目标和工作业绩）业务指导文档：业绩报表（目标和工作业绩）业务指导文档：业绩报表（目标和工作业绩）业务指导文档：业绩报表（目标和工
92、作业绩）感谢聆 听20162.7 补充内容说明2016第一章我们要求自发现课题，仅包含1-2个核心功能（登陆、注册不算核心功能）即可。本章要求根据该课题，在线提交提交该课题的前前景和范围文档景和范围文档，并尽可能尝试各种需求获取方法获取需求，编写用例使用说明文档用例使用说明文档，并在线提交。提交前景和范围文档、用例使用说明文档的同时，提交两份提交两份文档的度量结果度量结果表表，即自评结果表。表格如下。（注：表格请在本章相应的附件材料中下载。）在提交前景和范围文档、用例使用说明文档，以及两份文档自评的两张表格之外，还允许并建议提交获取需求的过程资料，例如面谈报告等，作为评分的参考。补充作业说明1
93、.注意区分业务需求与解决方案的界限，例注意区分业务需求与解决方案的界限，例如如何提高效率或者降低成本。如如何提高效率或者降低成本。2.保持实验的思路是提出问题，产生业务需保持实验的思路是提出问题，产生业务需求，形成高层解决方案。求，形成高层解决方案。3.提出的提出的Dirtyexample的系统规模要适中，的系统规模要适中，大约有大约有1-2个问题要解决，每个问题的难度也个问题要解决，每个问题的难度也要适中，每个问题解决方案的平均输入和输要适中，每个问题解决方案的平均输入和输出数量大约出数量大约4-8个，每个问题的平均特性数量个，每个问题的平均特性数量大约大约3-5个。个。补充作业说明补充作业
94、说明序号度量要求自评结果备注1文档格式是否相对规范、标准。 选择自评结果：优、一般、差2文档各项内容描述是否恰当、合理、完整。 选择自评结果：优、一般、差3文档中描述的问题有几个。 4文档中每个问题解决方案的平均输入数量。 5文档中每个问题解决方案的输出数量。 6文档中每个问题的平均特性数量。 1.注意系统边界的设置注意系统边界的设置2.参考目标模型的建立参考目标模型的建立3.安排需求获取活动。安排需求获取活动。4.严格按照获取方法的特点综合灵活运用。严格按照获取方法的特点综合灵活运用。5.本阶段分析模型为辅，不要求其模型的严谨本阶段分析模型为辅，不要求其模型的严谨性和完整性。性和完整性。补充
95、作业说明补充作业说明序序号号度量要求度量要求自自评评结结果果备注备注1 1文档格式是否相对规范、文档格式是否相对规范、标准。标准。 选择自评结果：选择自评结果：优、一般、差优、一般、差2 2文档各项内容描述是否文档各项内容描述是否恰当、合理、完整。恰当、合理、完整。 选择自评结果：选择自评结果：优、一般、差优、一般、差3 3需求获取的次数有多少。需求获取的次数有多少。 4 4使用了几种需求获取方使用了几种需求获取方法。法。 5 5用例数量共有几个。用例数量共有几个。 6 6平均用例的场景数量。平均用例的场景数量。 7 7平均用例的描述字数。平均用例的描述字数。 8 8最大用例描述的字数。最大用
96、例描述的字数。 2016感谢聆 听20162.8 面谈法获取需求2016需求获取是递进递进的！面谈法获取需求面谈，就是面对面地讨论。群体面谈，就是集体讨论方法，将众多涉众集中在一起，通过讨论发现需求，并在讨论中就需求问题达成一致，使得需求获取内容达到完整、统一，需求过程高效。面谈法获取需求面谈前准备面谈中控制和记录面谈后分析整理面谈过程分为面谈前准备、面谈中控制和记录、面谈后分析整理三个阶段。请观看短片，注意剧中细节，并回答问题。面谈法获取需求请您回答问题：短片中用到的需求获取方法是。面谈法获取需求面谈法获取需求会见者：XXX日期： 年 月 日被会见者：XXXX，XXXX 主题：会见目标：谈话
97、要点：被会见者观点：下次会见的目标：面谈报告格式范例3.面谈过程分析：（1）面谈前 需要做好相关准备，制定计划，准备开展面谈。面谈法获取需求课堂练习1：若您觉得短片中对以下问题有涉及，请选择“”，否则选“”。（1 1）阅读背景资料。（）阅读背景资料。（ ）（2 2）确定面谈主题和目标。（）确定面谈主题和目标。（ ）（3 3）选择被会见者，确定被会见者。）选择被会见者，确定被会见者。（ ）（4 4）安排会见时间。）安排会见时间。（ ）（5 5）选择会见地点。）选择会见地点。（ ）（6 6）预约准备被会见者。）预约准备被会见者。（ ）（7 7）确定问题和类型，准备会谈内容。）确定问题和类型，准备会
98、谈内容。（ ）（8 8）设计调查问卷、准备面谈工具、人员安排。）设计调查问卷、准备面谈工具、人员安排。（ ）面谈法获取需求3.面谈过程分析：（2）面谈中，面谈控制和记录面谈中，需要先开场白，介绍与会者，介绍本次会议的议程、内容梗概、目标，然后主持人按照事先预定的内容主持会议。最后感谢所有与会者。面谈法获取需求课堂练习2：若您觉得短片中对以下问题有涉及，请选择“”，否则选“”。面谈礼仪：进门时会见者主动和被会见者握手，尽快建立互相的信任和依赖。（ ）互相简短地介绍，主持者概要地说明会谈的原因、内容和目的，以及为什么选择他（或她）来参加面谈会议。（ ）就坐后准备好面谈工具和材料，例如电脑、投影仪、
99、录音机等设备，提醒被会见者将会发生的记录方式和要点，告知被会见者将会如何收集和处理数据，并保证机密性。（ ）一定要提前检查录音机、录像机等设备是否正常工作。如设备不正常却误认为正常工作，就很可能带来惨重损失。（ ）面谈中保持有礼貌地倾听。（ ）面谈法获取需求课堂练习2：若您觉得短片中对以下问题有涉及，请选择“”，否则选“”。面谈时：主持人要控制面谈过程，建立一些基本的会谈规则。例如，按时开始和结束会议。（ ）保证面谈主题，保持会议气氛。（ ）使用易接受、探究式提问方式，观察被会见者。（ ）控制面谈主题。面谈时很容易就发生主题偏题现象。与会者就不相关的主题讨论、争执等。主持人要能够及时发现，协调
100、和引导与会者回到会议主题上来。（ ）面谈时，记录员会完整地记录会谈的内容。（ ）面谈法获取需求课堂练习2：若您觉得短片中对以下问题有涉及，请选择“”，否则选“”。面谈结束时：面谈结束时，有几条注意事项。要注意面谈应该在45分钟到1小时内结束。时间太长，被访谈者容易感觉不耐烦或疲劳而导致效率低下。 （ ）要总结谈话要点。（ ）要感谢被会见者。（ ）最后应握手话别。（ ）面谈法获取需求总结面谈信息完成面谈报告复查整理(3)面谈后面谈法获取需求第案例：Android点餐系统第一次面谈一次面谈后，面谈报告：面谈ID：M1会见者：单凯，刘海涛，陈妍被会见者：戴佳维（餐厅经理）面谈日期：2016/10/9
101、面谈主题：目标模型和前景范围确认会见目标：对目标分析产生的业务目标进行确认，对项目前景和范围进行确认，分析过程中积累的问题提问谈话要点：被会见者观点：需求小组分析的项目业务目标是否存在问题？哪里存在问题？需求小组定义的优先级是否合理？系统是否同时面向管理者、服务生和顾客？系统对数据备份和恢复有什么要求？后续版本有什么变化？M餐厅规模为中小型连锁餐厅原则上希望系统操作尽可能简单，特性不要过于复杂，能够用简单的流程解决，就不要进行细化分割恶化用户体验定义的优先级基本是合理的目标基本合理系统面向管理者、服务生和顾客，但是开放权限不同，后台数据对顾客不可见保障数据安全性面谈法面谈法面谈法面谈法获取需求
102、获取需求是否对所有项目适用呢？面谈法面谈法面谈法面谈法获取需求获取需求是否面谈一次就够了呢？案例：Android点餐系统第二次面谈第二次面谈后，面谈报告：面谈ID：M2会见者：单凯，刘海涛，陈妍被会见者：戴佳维（餐厅经理）面谈日期：2015/10/15面谈主题：场景建立，用例细化会见目标：对于目标模型的每个具体子任务，得到用户的流程，描述针对执行流程，现场对不明确之处进行提问谈话要点：被会见者观点：制定促销策略的流程查看顾客订单的流程推送菜品和优惠的流程处理预约的流程处理下单的流程处理取号的流程处理支付的流程顾客评价的流程经理发布促销策略，填写促销策略具体内容，发布促销策略经理查看订单列表经理
103、进入添加菜品页面填写菜品和优惠定制，提交推送内容顾客进入预约页面，选择预约日期以及具体时间等信息，工作人员在处理页面进行处理，系统推送消息给顾客是否预约成功顾客进入下单页面选择菜品以及支付方式等信息，发送消息给餐厅工作人员，工作人员处理后，系统推送消息给顾客是否下单成功顾客进行取号操作，餐厅工作人员分配号码给顾客，并提醒大概时间，系统自动提示顾客取号结果顾客选择在线支付方式，进行支付，餐厅收到钱款后确认，系统提示顾客支付成功顾客支付成功后可对本次消费进行评价，在评论界面填写文字或提交图片评论并进行评分，顾客提交评论，系统显示评论并给予顾客积分奖励你你觉得被会得被会见者者观点是否准确不需再点是否
104、准确不需再细化？不是化？不是的。例如：的。例如：评论是否可以是否可以删除，除，评论是否可以修是否可以修改或追加？都没有改或追加？都没有说明。到明。到这里里为止，面止，面谈只只谈到到业务的正常流程，异常流程的正常流程，异常流程还未全面未全面铺开。所开。所以以还需需进一步地需求一步地需求获取。取。第二次面谈在第一次面谈的基础上，询问内容更进一步更深入更深入细致，主要致，主要围绕餐餐厅业务流程展开流程展开需求需求获取。取。面谈法获取需求面谈主题：场景确认，持续的用例发现和细节补充。会见目标：展示场景，串联图板，听取用户意见，明确积累的问题此处面谈法+故事板故事板原型法展开需求获取面谈法获取需求案例：
105、Android点餐系统第三次面谈案例：Android点餐系统第三次面谈提前取号业务流程确认：业务流程确认：使用故事板原型1.提前取号：提前取号：第三次面谈后，面谈报告：面谈ID：M3会见者：单凯，刘海涛，陈妍被会见者：戴佳维（餐厅经理）面谈日期：2015/10/27面谈主题：场景确认，持续的用例发现和细节补充会见目标：展示场景串联图板，听取用户意见，明确积累的问题谈话要点：被会见者观点：订单列表需要导出为excel表格方便打印吗？顾客是否可以取消预约取号下单支付评价的操作？评论被删除后顾客曾经因此获得的积分会扣除吗？顾客的评论是否可以在提交后再次编辑提交？支付方式借由其他支付平台实现还是系统实
106、现？经理查看订单后需要对订单进行细化操作吗？比如删除或者修改价格？对系统同时使用人数的预期？增加为可选操作，每次打印操作记入系统日志可查询预约可以在预约日期一天前取消，取号随时可以取消，取得的号码在顺序到达前都可以取消，已经完成的下单操作可以在消费前取消，已经完成的支付在消费前一天可以退款，现场支付的订单可以更改支付方式为线上或者线下由餐厅前台工作人员协同下完成，对菜品可以不做评价，评价后可以删除积分不会被扣除不可以再次编辑提交，消费后一天内有一次的追加评价机会借由支付宝或微信支付或绑定银行卡进行实现，或者选择线下现金付款已经结束整个流程的订单不可以修改，未完成的订单，经理有权修改价格或优惠策
107、略，不可以删除根据餐厅规模估算，同时在线500人以上案例：Android点餐系统第三次面谈第三次面谈在前两次面谈的基础上，询问内容涉及业务过程的各个细节，递进的过程非常明显。以讲故事的方式，很直观地展示给客户，客户容以讲故事的方式，很直观地展示给客户，客户容易接受和理解，并且能够很快发现该取号业务流易接受和理解，并且能够很快发现该取号业务流程中可能存在的问题，及时提出。若没有问题，程中可能存在的问题，及时提出。若没有问题，意味着取号业务流程得到客户确认。意味着取号业务流程得到客户确认。问题已已经涉及到系涉及到系统交互交互时产生的一些生的一些细节。面谈法获取需求案例：Android点餐系统第三次
108、面谈第四次面谈后，面谈报告：面谈ID：M4会见者：单凯，刘海涛，陈妍被会见者：戴佳维（餐厅经理）面谈日期：2015/11/3面谈主题：交互细节确认，持续的用例发现和细节补充会见目标：演示针对执行流程，现场对不明确之处进行提问谈话要点：被会见者观点：系统是否提供顾客评论时对表情的支持？针对顾客的菜品优惠推送是否可以关闭？顾客的评论是否可以由餐厅方面进行删除和回复操作？某顾客取号后取消了取号是否可以再次取号？没有进行注册的用户是否可以完整使用全部顾客权限内功能？注册系统必须使用手机号注册吗？提供emoji表情支持，可以发布图片评论可以关闭对恶意评论行为餐厅可以删除该评论，餐厅工作人员可以对顾客的提
109、问进行回复操作一天内不能超过5次重复取号行为没有注册的用户只能浏览菜品、优惠、餐厅信息等，不能进行预约下单取号支付评价等行为必须使用手机号注册案例：Android点餐系统第四次面谈这些些问题好像和系好像和系统功能关功能关联不大，可有可无，不大，可有可无，或属于特定或属于特定处理，所以是关于系理，所以是关于系统细节的的补充。充。第四次面谈的内容在前三次面谈的基础上，使用原型（后面会介绍）演示系统概况，并询问业务流程中不明确的每个地方。第四次面谈内容是对前三次面谈的补充和完善。至此，需求获取基本完成。面谈法获取需求案例：Android点餐系统第三次面谈需求列表4.Android点餐系统 以面谈法为
110、主 获取的(1)功能需求列表：ID需求内容问题域知识优先级UR1总经理可以制定促销策略中UR2总经理可以查看顾客订单信息PD1订单信息有下单时间，菜品内容，总金额，评价。高UR3总经理可以制定菜品和优惠中UR4顾客可以提前预订一天以后的座位高UR5顾客可以在线取号 高UR6顾客可以在线下单 高UR7顾客可以选择在线支付高UR8顾客可以对此次消费进行评分PD2评份内容为口味、服务、环境，还可对单一菜品进行评价高需求列表(2)性能需求列表：类别ID需求内容速度PR1更新数据库时间：1sPR2响应时间：0.5sPR3查询每条记录时间：0.5s容量PR4系统应该能储存至少10万条订单信息负载PR5系统
111、在100个用户并发时在90%的时间内能正常工作实时性PR6系统必须及时更新取号订单信息4.Android点餐系统 以面谈法为主 获取的需求列表(3)质量属性需求列表：4.Android点餐系统 以面谈法为主 获取的4.Android点餐系统以面谈法为主获取的需求列表(4)约束(5)其他需求 无5.面谈法的优点：开展面谈的条件简单，经济成本低。能获得包括事实、问题、被会见者观点、态度、信仰等各类信息，内容广泛。通过面谈，需求工程师可以和涉众间建立友好关系。面谈法获取需求5.面谈法的缺点：面谈比较耗时。被会见者地理分散情况下难以实现面谈。面谈对需求工程师的人际交往能力要求高。态度偏见、潜在知识、默
112、认知识、表述不清等各种问题不可避免地影响面谈结果。会见者不了解被会见者认知结构的情况下，面谈结果将比较糟糕。面谈法获取需求实际使用面谈法，需求方很多都是充当“孙子”的角色，造成客户方优越感强，不配合或者回避需求获取等。 但是我们认为需求方应该端正自己的形象，给客户以专业感，为客户着想，多方权衡，在理解客户真实意图以后，尽力提出比客户提出的更优的解决方案。面谈法获取需求补充： 面谈法一般会和其他需求获取方法配合使用。感谢聆 听20162.9原型法获取软件需求2016原型法获取软件需求面对面对不确定不确定的需求时，的需求时，我们通常采用原型法我们通常采用原型法原型(prototype)即样品、模型
113、的意思。把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。原型是一个演示系统原型是一种工具原型法获取软件需求1.1.什么叫原型？什么叫原型？什么叫原型？什么叫原型？2.原型法获取需求原型法获取需求案例案例：（1）提前取号：）提前取号：采用原型法，设计初始界面，获得用户对Android点餐系统界面要求和功能要求。原型法获取软件需求（2）提前订座：）提前订座：2.原型法获取需求原型法获取需求案例案例：采用原型法，设计初始界面，获得用户对Android点餐
114、系统界面要求和功能要求。原型法获取软件需求（3）在线下单：）在线下单：2.原型法获取需求原型法获取需求案例案例：采用原型法，设计初始界面，获得用户对Android点餐系统界面要求和功能要求。原型法获取软件需求（4）在线支付：）在线支付：2.原型法获取需求原型法获取需求案例案例：采用原型法，设计初始界面，获得用户对Android点餐系统界面要求和功能要求。原型法获取软件需求（5）首页：）首页：2.原型法获取需求原型法获取需求案例案例：采用原型法，设计初始界面，获得用户对Android点餐系统界面要求和功能要求。原型法获取软件需求3.3.原型法进行的步骤：原型法进行的步骤：确定用户的基本需求由用户
115、提出对新系统的基本要求，如功能、界面的基本形式、所需要的数据、应用范围、运行环境等，开发者根据这些信息估算开发该系统所需的费用，并建立简明的系统模型。原型法获取软件需求3.3.原型法进行的步骤：原型法进行的步骤：构造初始原型系统开发人员在明确了对系统基本要求和功能的基础上，依据计算机模型，以尽可能快的速度和尽可能多的开发工具来建造一个结构仿真模型，即快速原型构架。原型法获取软件需求3.3.原型法进行的步骤：原型法进行的步骤：运行、评价、修改原型快速原型框架建造成后，展示给用户。此时，要充分进行开发人员和用户之间的沟通，尤其是要对用户提出的不满意的地方进行认真细致的反复修改、完善，直到用户满意为
116、止。原型法获取软件需求3.原型法进行的步骤：原型法进行的步骤： 形成最终的软件系统 如果用户和开发者对原型比较满意，则将其作为正式原型。经过双方继续进行细致的工作，把开发原型过程中的许多细节问题逐个补充、完善、求精，最后形成一个适用的软件系统。原型法获取软件需求4.4.原型的分类原型的分类原型可分为抛弃式、演化式两种。 淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。“丢弃”式原型针对生命周期的需求确定阶段, 它集中在理解的最少的需求上。 演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行
117、规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。原型给用户看时，用户不接受，反感强烈，则只能抛弃原型。原型展示给用户时，用户部分接受，则继续修改不接受部分，直到用户满意，此时原型为演化式。5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（1）提前取号：）提前取号：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（1）提前取号：）提前取号：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（1）提前取号：）提前取号：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（1）提前
118、取号：）提前取号：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（1）提前取号：）提前取号：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（1）提前取号：）提前取号：（2）提前订座：）提前订座：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（2）提前订座：）提前订座：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（2）提前订座：）提前订座：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（2）提前订座：）提前订座：5.案例：使用故事板原型确认确认Androi
119、d点餐系统业务流程。业务流程。（2）提前订座：）提前订座：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（2）提前订座：）提前订座：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（3）在线下单：）在线下单：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（3）在线下单：）在线下单：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（3）在线下单：）在线下单：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（3）在线下单：）在线下单：5.案例：使用故事板原型确认确认
120、Android点餐系统业务流程。业务流程。（4）在线支付：）在线支付：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（4）在线支付：）在线支付：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（4）在线支付：）在线支付：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（5）评价：）评价：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（5）评价：）评价：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（6）制定促销策略：）制定促销策略：5.案例：使用故事板原型确认
121、确认Android点餐系统业务流程。业务流程。（6）制定促销策略：）制定促销策略：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（6）制定促销策略：）制定促销策略：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。（6）制定促销策略：）制定促销策略：5.案例：使用故事板原型确认确认Android点餐系统业务流程。业务流程。6.6.原型法的优点原型法的优点符合人们认识事物的规律，系统开发循序渐进，鼓励用户积极参与，有助于解决用户之间的差异；能给用户一个对最终系统的直观感受；开发周期短，成本相对低；反复修改，确保较好的用户满意度。由于有用户的直接
122、参与，系统更加贴近实际；易学易用，减少用户的培训时间；应变能力强。原型法获取软件需求6.6.原型法的缺点原型法的缺点不适合大规模系统的开发；开发过程管理要求高，整个开发过程要经过“修改评价再修改”的多次反复；用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心；开发人员易将原型取代系统分析；缺乏规范化的文档资料。原型法获取软件需求7.7.原型法适用范围原型法适用范围处理过程明确、简单的系统；涉及面窄的小型系统。原型法获取软件需求7.7.原型法不适用范围原型法不适用范围大型、复杂系统，难以模拟；存在大量运算、逻辑性强的处理系统；管理基础工作不完善、处理过程不规范；大量批处理系统。原型法
123、获取软件需求8.案例分析：案例分析：Nordic Designs 是一家专营Scandinavia 当代家具的连锁企业，它已经发布了一则夸耀其配送信息系统原型的公司简讯。简讯报道声称：“我们的配送信息系统原型一发布就投入使用了。绝对没有任何修改的必要，经理们说它是追踪家具配送的最佳解决方案。不久就可以你们商店中接触原型了。”(1)这则报道的作者对原型化方法概念明显存在什么样的误解？(2)如果用户期望原型“绝对没有任何修改的必要”的话，列出原型设计者可能会面临的问题。（1）答：原型是不完备系统，千万别误以为原型是系统的最终样子。（2）答：使用原型是有一定的风险的。原型设计者可能会面临的问题：多次
124、反复修改，用户对系统失去信心，文档资料不规范等。原型法获取软件需求感谢聆 听20163-1需求分析概述一沓面谈记录很多用例文件很多用例文件各种硬数据各种硬数据3-1需求分析概述需求分析的目的，其实就在于通过一定的分析决定做哪些需求不做哪些需求，哪些需求先做哪些需求后做。需求有真假、强弱、缓急一、需求分析一、需求分析到底做到底做什么？什么？准确地回答“系统必须做什么？”需求分析是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作，概括为分解分解分解分解、提炼提炼提炼提炼、消消消消除矛盾除矛盾除矛盾除矛盾三个方面。1分解采用自顶向
125、下的方法(1)业务流程为主线索的分解结构1分解采用自顶向下的方法(2)程序结构为主线索的分解结构1分解采用自顶向下的方法(3)基于场景的分解结构1分解采用自顶向下的方法(4)基于数据的分解结构2提炼采用自底向上的方法提炼出系统的总体功能结构，更全面的描述系统。3及时发现分析中的矛盾并消除矛盾例如：资产管理人员希例如：资产管理人员希例如：资产管理人员希例如：资产管理人员希望资产管理严谨，报销望资产管理严谨，报销望资产管理严谨，报销望资产管理严谨，报销前入库，采购人员希望前入库，采购人员希望前入库，采购人员希望前入库，采购人员希望报销流程简化。报销流程简化。报销流程简化。报销流程简化。二、二、建模
126、建模的目标与要点的目标与要点目标目标：u帮助需求分析员按照实际情况或按需要的样式对系统进行可视化；u提供一种详细说明系统的结构或行为的方法；u给出一个指导系统构造的模板；u对需求分析所做出的决策进行文档化。要点：u设计要考虑到计划之外的变化；u设计要文档化；u用可视化的模型表达架构，有助于理解变化所代表的含义。建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识。三、三、正确认识正确认识UMLUML是统一建模语言（UnifiedModelingLanguage）使用频使用频率率图名图名功能功能关注要关注要点点主体主体用例图说明角色和使用场景之间的关系人活动图说明业务流
127、程，以及业务活动的步骤事顺序图描述对象之间的交互物类图说明业务实体之间的关系，体现结构规则物辅助辅助构件图说明主题域划分以及他们之间的服务接口接口部署图描述系统的部署环境，体现设计约束设计约束需求阶段常用的图四、四、常见需求分析方法常见需求分析方法方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。目前常见的需求分析方法有结构化分析（SA）、面向对象分析（OOA）和面向问题域分析（PDOA）三种方法。3-2需求分析方法结构化分析（SA）需求分析方法:面向对象分析（OOA）面向问题域分析（PDOA）3-2需求分析方法常见的结构化分析技术包括数据建模、过程建模、行为建模、过程/数据
128、关系建模和信息工程方法等一、结构化分析（StructuredAnalysis）1数据建模数据建模：实体实体关系图关系图EntityRelationshipDiagram简单情况下ERD建模分四步完成：从描述信息中辨识实体确定实体的标识符建立实体间关系添加详细的描述信息1数据建模数据建模：实体实体关系图关系图EntityRelationshipDiagram例如：大学实行学分制，学生可根据自己的情况选课。每名学生可同时选修多门课程，每门课程可由多位教师主讲；每位教师可讲授多门课程。学生学生选修选修讲授讲授教师教师课程课程指导指导1mnmnm2过程建模：数据流图过程建模：数据流图DataFlowD
129、iagram数据流图（DFD）就是组织中信息运动的抽象，是信息逻辑系统模型的主要形式。2过程建模过程建模：数据流图数据流图DataFlowDiagramDFD由四种基本符号组成：1）外部项（外部实体）2）加工3）数据流4）数据存储（文件）2过程建模过程建模：数据流图数据流图DataFlowDiagram示例：银银行行取取款款系系统统简单银行取款应用描述：储户将填好的取款单、存折交银行，银行做如下处理：审核并查对帐目，将不合格的存折、取款单退回储户，合格的存折、取款单送取款处理。处理取款修改帐目，将存折、利息单、结算清单及现金交储户，同时将取款单存档。画出银行取款处理数据流图。2过程建模过程建模
130、：数据流图数据流图DataFlowDiagram第一步，画出关联数据流图。2过程建模过程建模：数据流图数据流图DataFlowDiagram第二步，逐层分解加工，画出下层DFD。2过程建模过程建模：数据流图数据流图DataFlowDiagram数据字典数据字典是一个储存库，包含软件使用和产生的所有数据对象的描述，其中也包括DFD当中数据流和数据存储的定义。2过程建模过程建模：数据流图数据流图DataFlowDiagram数据字典符号符号含义含义说明说明=表示定义为用于对于=左边的条目进行确切的含义+表示与关系X=a+b表示X由a和b共同构成,表示或关系X=ab与X=a,b等价，表示X由a或b组
131、成()表示可选项X=(a)表示a可以在X中出现，也可以不出现表示重复大括号中的内容重复0到多次Mn表示规定次数的重复重复的次数最少m次，最多n次“”表示基本数据元素 “”中的内容是基本数据元素，不可再分.连接符Month=1.12表示month可取112中的任意值*表示注释内容为注释信息2过程建模过程建模：数据流图数据流图DataFlowDiagram四类条目：数据流条目数据项条目数据文件条目数据加工条目数据字典的任务是对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。2过程建模：过程建模：数据流图数据流图DataFlowDiag
132、ram1)数据流条目数据流名：发票说明：用作学生已付书款的依据数据流来源：来自加工“审查并开发票” 数据流去向：流向加工“开领书单”。数据流组成：学号+姓名+书号+单价总价+书费合计2过程建模：过程建模：数据流图数据流图DataFlowDiagram2)数据项条目例如例如：出勤表中的职工号数据项在数据字典中的条目描述为数据项名称：职工号数据项别名：employee_no 说明：本单位职工的惟一标识类型：字符串长度：6取值范围及含义：12位(00.99)为部门编号：36位(XX0001.XX9999)为人员编号2过程建模：过程建模：数据流图数据流图DataFlowDiagram3)数据文件条目例
133、如例如：工资系统中的职工工资档案文件在数据字典中的条目描述为数据文件名称：工资档案说明：单位职工的基本工资、各项津贴及补贴信息数据文件组成：职工号+国家工资+国家津贴+职务津贴+职龄津贴+交通补贴+部门补贴+其他补贴组织方式：按职工号从小到大排列存取方式：顺序存取频率：1次/月2过程建模：过程建模：数据流图数据流图DataFlowDiagram4)数据加工条目数据字典的数据加工条目中应包含的主要内容有：数据加工名称、加工编号、说明、输入数据流、输出数据流、加工逻辑等。其他几种结构其他几种结构化分析方法化分析方法行为建行为建模：状模：状态态(转转换换)图图/矩阵矩阵过程过程/数据关数据关系建模：
134、系建模：功能实功能实体体矩阵矩阵信息工信息工程程方法：方法：功能分功能分解解图和图和过程过程依依赖图赖图行为模型常用状态转换图（简称状态图）来描述，它又称为状态机模型。通过功能实体矩阵描述过程与数据关系。信息工程法提供了建立企业模型、数据模型和流程模型的技术手段，其基础和核心是战略数据规划。信息工程法在很大程度上是一种面向技术的方法。3-2需求分析方法OOA的大致方法是标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类之间的关系建模。二、面向对象分析（ObjectOrientedAnalysis）1 1用例图用例图Use-CaseDiagram基本用例模型基本用例模型反
135、映行为需求，用于对行为需求建立独立于技术的模型，一般在需求获取阶段建立，也被称为业务用例模型或者抽象用例模型。系统用例模型系统用例模型反映的是分析结果，用于为行为分析建模，描述用户与系统协同工作的细节，包括对用户界面特点的描述，一般在需求分析阶段建立，也称为具体用例模型或者详细用例模型。1 1用例图用例图Use-CaseDiagram从阶段上来说，基本用例在需求获取阶段构建，系统用例在需求分析阶段构建；从内容上来说，基本用例使用应用领域的语言和用户的语言进行表达，系统用例分析和描述所要解决的问题所提出的需求，同时和对用户界面将来外观的初步构思结合。基本用例和系统用例的区别由两个方面体现：1 1
136、用例图用例图Use-CaseDiagram示例示例：新闻管理系统需求系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。1 1用例图用例图Use-CaseDiagram示例示例：新闻管理系统需求业务用例图1 1用例图用例图Use-CaseDiagram示例示例：新闻管理系统需求系统用例图1 1用例图用例图Use-CaseDiagram示示例例：新闻管理系统需求用例名用例名称称登录系统登录系统用例简用例简述述用户登录CMS系统用例图用例图主要流主要
137、流程程1）用户输入用户名和密码2）选择用户类型3）点击登录按钮替代流替代流程程3a）“用户名或密码错误”，系统出现用户名或密码错误的提示信息，回到主要流程1，由用户重新输入3b）“输入的用户名与类型不符”，系统出现提示信息，回到主要流程1，由用户重新输入3c）当用户点击取消按钮时，取消登录2 2类图类图Class Diagram2 2类图类图Class Diagram关联聚合/组合泛化2 2类图类图Class Diagram2 2类图类图Class Diagram3交互图（顺序图交互图（顺序图/通信图通信图）Interaction（Sequence/Communication）Diagram该
138、图是用户登录的序列图，注册会员为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行，UserServices为业务组件，调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定用户名、密码是否匹配，从而完成业务功能。3交互图（顺序图交互图（顺序图/通信图通信图）Interaction（Sequence/Communication）Diagram协作图（通信图）也是一种交互图，它强调收发消息的对象的组织结构，协作图和序列图是可以相互转换的。在很多情况下，协作图主要用来对单一的、顺序的控制流建模，同
139、时它也可以用来对包括迭代和分支在内的复杂控制流进行建模。协作图包含一组对象和链(link)，用于描述系统的行为是如何由系统的组成成员协作实现的。4 4活动图活动图Activity Diagram活动图是用来描述业务活动图是用来描述业务用例用例实现的工作流实现的工作流程。程。示例：示例：管理员管理员添加菜品信息，管理员添加菜品的活添加菜品信息，管理员添加菜品的活动图动图见见下下图图。5 5状态图状态图StateChartDiagram状态图(State Chart Diagram)是描述一个实体基于事件发生状态转变的动态行为，展示了该实体如何根据当前状态对不同的事件做出相应反应，通常我们创建一个
140、UML状态图是为了研究类、角色、子系统、或组件的复杂行为。3-2需求分析方法结构化分析方法和面向对象方法的比较。三、两种方法比较两种方法的比较 结构化分析（SA）及其相应的派生方法，最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型上。 面向对象分析（OOA）是当今主流的方法。OOA要求所有的系统均可以按照对象的特点来建模。 OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。结构化分析方法面向对象分析方法两种方法的比较结构化分析方法面向对象分析方法SA和OOA还有几点相同特性：（1）主要模型是结构模型；（2）
141、通常焦点集中在对解系统的建模上；（3）两种方法都较少地应用于需求获取领域；（4）分析与内部设计之间没有明显差异。3-2需求分析方法包括理清项目系统框架与脉络和确定需求细节，使用的项目为贯穿课程的“Android点餐系统 ”。本节介绍了常用的两种需求分析方法，在后续的介绍中将综合使用这两种方法分两个阶段通过案例进行需求分析过程介绍。3-3需求分析案例第一阶段：理清业务与流程需求分析案例第二阶段：确定需求细节“Android点餐系统”项目案例需求获取资料介绍如下：（1）目标和范围 本软件主要作用是为点餐者提供一套可以在移动设备（手机、平板）上运行的点餐软件。系统分为前台和后台，前台是点餐者使用的，
142、点餐者可以在移动设备上查看餐馆所有的菜目、价格、简单的菜品介绍以及餐馆的特色菜介绍，同时点餐者还可以查看、取消自己已经挑选的菜品，最后上传订单。后台是管理员使用的，管理员可以在后进行订单管理、用户管理、菜谱管理等。 （2）系统角色和职责系统的使用人群包括两类，一类是普通的用户，另一类是管理员（经过培训或是专业人员）。管理员：系统的维护，订单管理、菜品的增删。普通用户：注册账号，点餐、座位预订。“Android点餐系统”项目案例需求获取资料介绍如下：序序号号功能要功能要求求需求说明需求说明1查询菜品用户可以查看菜品的基本介绍，包括简单的材料和烧制过程。户可以查看菜品的价格、剩余数量、图片等。户可
143、以查看当日的特色菜和特价菜推荐。2设置菜品管理员可以不断更新维护菜品信息，修改菜品价格，删除不再供应的菜品，菜品信息里包括菜名、菜的简单介绍、图片、价格、数量、分类等。3顾客下单用户可以查看所有菜品，选择菜品及数量后下单，如果选择在餐厅用餐，还可以提前预订座位。4订单处理管理员可以查看到用户的订单情况，通过修改订单状态对订单进行处理，表示订单是否完成，对恶意订单或已经取消的订单可以进行删除。用户可以查看自己的订单，如果订单的状态是未完成，用户可以修改或取消自己的订单。5数据处理管理员可以定期将数据备份到本地，遇到数据库故障时可以恢复数据库，打印数据库相关数据。（3）系统处理功能要求见下表。“A
144、ndroid点餐系统”项目案例需求获取资料介绍如下：（4）系统其他要求本系统客户端要求符合大众操作习惯，与网上其他的Android系统App操作方式保持基本一致。餐馆要求每笔订单交易误差不得超过1角，每天交易额的误差不得超过100元。5年内价位在500元以上的Android手机都可以流畅运行该系统。“Android点餐系统”项目案例需求获取资料介绍如下：3-3需求分析案例以Android点餐系统为例。第一阶段：理清业务与流程一、一、业务业务流程分析流程分析1.1.业业务务流流程程分分析析一是理解流程的层次性；二是了解流程的类型；三是掌握以业务事件识别、寻找流程的技巧。基于Android平台的点
145、餐系统的总体流程包括的步骤有：（1）顾客在智能手机上登录点餐系统客户端后，自动进入菜谱界面，查看菜谱；（2）顾客选择菜品进行下单；（3）顾客选择菜品数量，若需在餐厅用餐还需选择座位号；（4）选择完成并确定后，提交订单；（5）订单提交后，订单数据会上传到服务器；（6）订单提交后，顾客可以在客户端查看自己的订单情况；（7）在管理员未确认订单之前，顾客可以对订单进行修改或取消操作；（8）管理员登录点餐系统服务器端，对用户订单进行确认；一、一、业务业务流程分析流程分析2.跨跨职职责责流流程程图图应应用用具体来说，我们应该先找到业务事件的负责人，然后通过设问的方式，让他描述响应该业务事件所进行的活动，说
146、明活动的执行岗位以及它们之间的关系、数据传递。一、一、业务业务流程分析流程分析3 3. .活活动动图图应应用用 活动图是一种表述过程机理、业务过程以及工作流的技术。本系统的下单活动图可以参看右图。一、一、业务业务流程分析流程分析4.4.数数据据流流程程图图应应用用客户端数据流程图服务器端数据流程图二、业务实体分析二、业务实体分析1 1业务业务实体分实体分析任务析任务概述概述业务实体分析的产物有两种可选的模型，包括类图和E/R模型也叫实体关系图。二、业务实体分析二、业务实体分析2 2. .类类图图1）领域建模方法领域建模时，其工作主要就是识别标识类、明确类之间的逻辑关系和数量关系以及添加重要的结
147、构规则三个方面。二、业务实体分析二、业务实体分析2 2. .类类图图使用名词分析法发现类和对象。1用例描述：用例描述：1.经经理理开开始始制制定定促促销销策策略略2.经理经理制定制定促销策略促销策略3.系系统统返返回回当当前前促促销销策策略略经经理理重重复复步步骤骤2-3，直直至制定所有促销策略至制定所有促销策略4.经经理理结结束束制制定定促促销销策策略略5.系系统统返返回回当当前前促促销销策策略略确定对象：确定对象：经经理理，促促销销策略策略概念类：概念类：经经理理，促促销销策略策略二、业务实体分析二、业务实体分析2 2. .类类图图2用例描述：用例描述：1. 经经理理查查看看预预约约2.
148、系系统统返返回回预预约列表约列表确定对象：确定对象：经经理理，预预约约，预预约约列列表表概念类：概念类：经经理理，预预约约，预约列表预约列表摒弃对象：3用例描述：1.经理查看取号2.系统返回取号列表确定对象：经理，取号，取号列表概念类：经理，取号，取号列表摒弃对象：4用例描述：1.经理查看订单2.系统返回订单列表确定对象：经理，订单，订单列表概念类：经理，订单，订单列表二、业务实体分析二、业务实体分析2 2. .类类图图5用例描述：用例描述：1.顾客顾客请求请求预约预约2.系系统统向向经经理理发发送送预预约约请求请求3.经理经理处理处理预约预约请求请求4.系系统统提提醒醒经经理理处处理理成成功
149、功5.系系统统返返回回顾顾客客预预约约信信息息确定对象：确定对象：顾顾客客，预预约，经理约，经理概念类：概念类：顾顾客客，预预约，经理约，经理摒弃对象：6用例描述：1.顾客请求取号2.系统向经理发送取号请求3.经理处理取号请求4.系统提醒经理处理成功5.系统返回顾客取号信息确定对象：顾客，取号，经理概念类：顾客，取号，经理二、业务实体分析二、业务实体分析2 2. .类类图图7用例描述：用例描述：1.顾客顾客请求请求下单下单2.系统系统返回返回促销策略促销策略3.顾客顾客填写填写订单订单4.系系统统向向经经理理发发送送下下单单请请求求5.经理经理处理处理下单下单请求请求6.系统系统提醒提醒经理经
150、理处理成功处理成功7.系统系统返回返回顾客订单顾客订单信息信息确定对象：确定对象：顾顾客客，下下单单，促促销销策策略略，订订单单，经理经理概念类：概念类：顾顾客客，下下单单，促促销销策策略略，订单，经理订单，经理摒弃对象：8用例描述：1.顾客请求支付2.系统向经理发送支付请求3.经理处理支付请求4.系统提示顾客可以支付5.顾客支付6.系统提示经理顾客支付7.经理回应支付8.系统提示顾客支付结果9.系统提示经理支付结果确定对象：顾客，支付，经理概念类：顾客，支付，经理二、业务实体分析二、业务实体分析2 2. .类类图图9用例描述：用例描述：1.顾客顾客发表发表评论评论2.系统系统返回返回评论列表
151、评论列表确定对象：确定对象：顾顾客客，评评论论，评论列表评论列表概念类：概念类：顾顾客客，评评论论，评论列表评论列表最终发现的所有概念类如下：经理，顾客，促销策略，预约，预约表，取号，取号表，支付，下单，订单，订单信息列表，评论，评论列表二、业务实体分析二、业务实体分析2 2. .类类图图2）建立类之间的关联二、业务实体分析二、业务实体分析2 2. .类类图图3）添加类的重要属性二、业务实体分析二、业务实体分析2 2. .类类图图分析模型中有3种十分有用的构造型即实体类、控制类和边界类。实体类即实体对象的抽象；控制类即控制对象的抽象；边界类即边界对象的抽象。二、业务实体分析二、业务实体分析3
152、3. . E/E/R R图图应应用用基基础础概念模型和逻辑模型有什么区别呢？它们实际上是对“需求视图”与“开发视图”的区分。换句话说，概念模型是需求人员的视图，等价于现在出镜率很高的领域模型；而逻辑模型是开发人员(包括设计人员)的视图，它约等于面向对象分析与设计方法中提到的“分析模型”。三三、角色与使用角色与使用场场景景分析分析在传统的结构化分析与设计方法中，整个分析视角是站在解决方案域的，很容易产生对问题域分析不足的结果。用例分析技术的关键是“发现使用系统的角色(参与者)，了解并梳理这些角色将如何使用系统(场景)”，从而更好地完成“人”的视角的需求梳理。三、三、角色与使用角色与使用场场景分析
153、景分析1. 参与者参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。本例中参与者包括 ：普通用户与管理员。三、三、角色与使用角色与使用场场景分析景分析2. 用例实例与用例用例实例(即场景)是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果，一个用例定义一组用例实例。用例是对一组用例实例(场景)的抽象，也就是说，用例是有路径(基本事件流、扩展事件流、子事件流等)的。一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。 三、三、角色与使用角色与使用场场景分析景分析3. 参与者与用例之间的关系、用例与用例之间的关系、参与者与参与者的关系参与者与用例的关系体现在一个
154、参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。用例之间的关系有包含、扩展和泛化。参与者之间的关系只有一种，那就是泛化。三、角色与使用场景分析事半功倍的问题：你平时都做什么？（参与者目标）这件事是谁交办的？做完了你需要通知或传达给认证吗？做这件事情你都需要填写些什么表格吗？三、三、角色与使用角色与使用场场景分析景分析示例：边界确定(去除非EndUser的职责带区)确定角色(对剩下的职责带区进行角色化)确定用例三、三、角色与使用角色与使用场场景分析景分析示例：边界确定确定角色确定用例主要参与者主要参与者用例用例普通用户普通用户1.普通用户注册普通用户注册2.普通用户登录普通用户登录3.
155、用户修改密码用户修改密码4.查看菜谱查看菜谱5.点餐下单点餐下单6.查看特色菜推荐信息查看特色菜推荐信息7.查看订单信息查看订单信息管理员管理员1.管理员登录管理员登录2.菜品信息管理菜品信息管理3.用户信息管理用户信息管理4.订单管理订单管理5.特色菜信息管理特色菜信息管理6.数据库维护数据库维护三、三、角色与使用角色与使用场场景分析景分析菜品信息管理用例，它的参与者是管理员，用例是菜品信息管理，菜品信息管理用例包含查看菜品信息、添加菜品、删除菜品、修改菜品信息四个子用例，菜品信息管理是抽象出的一个基用例，是为了简化用例的描述。三、三、角色与使用角色与使用场场景分析景分析4用例分析技术应用要
156、点在上面用例分析的基础上，来讨论一下用例分析的几个技术应用要点。（1）用例真的有粒度吗？（2）用业务动词命名用例十分重要。（3）采用先事后人的方式分析是要点。四、第一阶段产物四、第一阶段产物1工作任务说明以为某餐饮公司开发的Android点餐系统为例，详细介绍该项目的第一阶段分析情况。在需求分析的第一阶段，核心任务就是结合业务流程、报表的需求，梳理出结构框架和行为脉络，为第二阶段的需求分析工作建立基础，指出方向。四、第一阶段产物四、第一阶段产物1工作任务说明领域模型和用例模型：管理员主要负责系统的维护，订单管理、菜品的增删。希望通过这样一个系统能够吸引顾客，同时希望减少人力成本，获得更高的效率
157、和收益。普通用户主要使用这个系统来实现注册账号，点餐、座位预订，节约时间。四、第一阶段产物四、第一阶段产物2业务事件分析“Android点餐系统”的总体业务流程包括如下步骤：（1）顾客在智能手机上登录点餐系统客户端后，自动进入菜谱界面，查看菜谱；（2）顾客选择菜品进行下单；（3）顾客选择菜品数量，若需在餐厅用餐还需选择座位号；（4）选择完成并确定后，提交订单；（5）订单提交后，订单数据会上传到服务器；（6）订单提交后，顾客可以在客户端查看自己的订单情况；（7）在管理员未确认订单之前，顾客可以对订单进行修改或取消操作；（8）管理员登录点餐系统服务器端，对用户订单进行确认。标识标识出了查出了查看菜
158、谱、点餐看菜谱、点餐下单、菜品信下单、菜品信息管理、用户息管理、用户信息管理、订信息管理、订单管理、特色单管理、特色菜信息管理、菜信息管理、数据库维护等数据库维护等业务事件。业务事件。四、第一阶段产物四、第一阶段产物2业务事件分析以“菜品信息管理”业务事件为例四、第一阶段产物四、第一阶段产物2业务事件分析 服务器端的主要作用在于实现与数据库的交互，完成相应数据的增加、修改及删除，具体的操作流程如下：（1）管理员输入正确的登录名和密码来登录系统；（2）管理员成功登录系统后，可对系统的相关信息进行管理。四、第一阶段产物四、第一阶段产物2业务事件分析基于Android平台的点餐系统采用C/S和B/S
159、的混合模式结构，其中手机客户端的实现采用的是C/S模式，而服务器端基于B/S模式进行实现。四、第一阶段产物四、第一阶段产物2业务事件分析参与该系统的类分别是用户、管理员、订单、菜品、座位、菜品类别。四、第一阶段产物四、第一阶段产物3报表分析对于报表而言，分析工作可以分成why(目标)、what(内容)与How(展现形式)三个层次。以“订单业务报表”为例其要解决的问题包括角色查询、目的、相关场景与查询频率等方面的内容。四、第一阶段产物四、第一阶段产物4抽象与整理客户端:客户端包括的主要功能有注册功能、登录功能、查看菜品功能、下单功能、选座功能、查看订单功能等。服务器端：根据前文的分析可知道，服务
160、器端包括的功能有登录功能、用户管理功能、菜谱管理、订单管理等。系统管理模块包含数据备份、数据恢复及数据打印功能四、第一阶段产物四、第一阶段产物4抽象与整理四、第一阶段产物四、第一阶段产物5填充需求规格说明框架通过以上分析，就可以完成结构框架和行为脉络的填充，同时将其填充到软件需求规格说明书中。需求规格说明课后可以在网站下载参考。3-3需求分析案例以Android点餐系统为例。第二阶段：确定需求细节一、确定行为需求的细节一、确定行为需求的细节1.用例的灵活应用根据行为需求的特点，可以将其分成“业务功能、报表功能、接口、技术支撑”4种类型。统一封装成用例，但在具体细节描述方面，可以对其进行灵活处理
161、。一、确定行为需求的细节一、确定行为需求的细节2.用例描述模板 针对业务功能类的用例来说，其需要整理的内容主要包括事件流、相关需求与功能点、界面原型、规则与约束4个方面，描述的方法可以采用通用的用例描述模板来组织。 以“Android点餐系统”为例。一、确定行为需求的细节一、确定行为需求的细节2.用例描述模板以“Android点餐系统”查看菜品信息为例。一、确定行为需求的细节一、确定行为需求的细节3.相关需求整理(1)用户原始需求 将需求捕获阶段获得的用户原始需求，通常每个原始需求是以一句话的形式整理到相应的用例中，它可以更好地建立用户原始需求和软件需求(即用例)之间的映射。 (2)相关功能点
162、 在需求规格说明书中除了可以将用户原始需求归类整理进来，作为开发时的重要参考依据之外，有时可能还会涉及一些无法有效地表述在事件流中的小功能点。 一、确定行为需求的细节一、确定行为需求的细节4.界面原型(1) 要点 (2) 交互不要忽略 (3) 别让界面掩盖本质一、确定行为需求的细节一、确定行为需求的细节4.界面原型一、确定行为需求的细节一、确定行为需求的细节5.规则与约束规则大致可以分为：行为规则：或称为功能规则、业务规则，它是指和业务逻辑、业务流程相关的规则。 结构规则：或称为数据规则，它是指和业务实体、属性、派生属性相关的规则。 界面规则：它是指和用户界面相关的规则。 一、确定行为需求的细
163、节一、确定行为需求的细节5.规则与约束约束分成以下几种类型：性能指标等非功能要求软、硬件环境限制技术选择限制用户特点及环境限制二、确定结构需求的细节二、确定结构需求的细节(1)领域模型的组织(2)数据窗口分析(3)数据组成与格式三、第二阶段产物三、第二阶段产物用例描述事件流分析相关需求用户界面原型规则与约束三、第二阶段产物三、第二阶段产物点餐下单需求：点餐下单需求：1）需求名称：用户点菜下单。2）简要描述：运行Android点餐系统的用户登录系统后。用户下单点菜，若是用户需要在餐馆用餐，则需要选取座位号。用户选好座位以及菜品后点击下单即可完成点菜下单。3）主要参与者：Android点餐系统普通
164、用户。4）步骤描述序序号号入口条件入口条件操作操作出口条件出口条件1用户已经登录系统用户查看菜谱用户在菜单界面2用户登录菜单界面选取自己想要的菜品，点击下单用户进入订单界面3用户进入订单界面根据座位的空余情况点击选取自己想要的座位号，最后完成订单用户完成订单预订三、第二阶段产物三、第二阶段产物5）用例描述6）优先级：重要3-4其他需求分析接口需求其他需求分析:非功能需求的追踪设计约束3-4其他需求分析描述接口重点的组成包括使用者、内容与格式、设计约束与要求。一、接口需求一、接口需求描述接口重点的组成包括使用者、内容与格式、设计约束与要求。1使用者包含使用者名称、业务目的、使用时机、使用频率。2
165、内容与格式包含交互过程说明以及数据包说明。3设计约束与要求包括协议格式要求、性能要求、环境限制。3-4其他需求分析软件工程产品质量（GB/T16260-2006）中对软件的每个质量特性与子特性都有定义。二、非功能需求的追踪二、非功能需求的追踪1质量特性分析二、非功能需求的追踪2确定非功能需求树3-4其他需求分析“非技术因素决定的技术选型”采用表格法表示；“预期的使用环境”用条目化文本表示；“预期的软硬件环境”部署图表示三、设计约束3-4其他需求分析以“Android点餐系统”为例。四、其他需求示例1性能需求1.1精度餐馆要求每笔订单交易误差不得超过1角，每天交易额的误差不得超过100元。优先级
166、：普通1性能需求1.2时间特性要求1、前台客户端要求登录时间不等超过0.5秒，选择菜品、座位后下单的响应时间不得超过1秒，其他的一些操作响应时间一般不得超过0.5秒。2、后台服务器要求管理员操作保持流畅，用户下单后后台需要在5秒内看见用户的订单。优先级：普通1性能需求1.3灵活性在订单未审核时，可以取消或修改订单，一旦审核，则不能再修改。1、客户端5年内价位在500元以上的Android手机都可以流畅运行Android点餐系统1性能需求2、服务端保持可移植性，方便硬件设备的更换。操作方式上应该能够满足鼠标和键盘任意切换的需要；能够支持Window95、Window98、Windows2000、
167、WindowsXP、Windows7及Ubuntu、Debian、Mandrake、RedHatLinux运行环境。留有与其他系统的接口。优先级：普通1性能需求1.4并发性要求可以同时有200人在线点餐。优先级：普通1.5故障处理需求服务器若出现报错、死机等特殊错误时可在3分钟内完成自动恢复。系统的出错率低于千分之一。优先级：普通3质量属性3.1易用性与可用性：1、点餐系统客户端要求符合大众操作习惯，与网上其他的Android系统App操作方式保持基本一致。2、系统维护期间应保证系统能正常工作。优先级：普通4运行环境需求4.1设备需求前台客户端运行在环境Android2.2及以上版本的移动设备
168、上。服务器可以运行在常规的桌面机上，需要配置JDK、tomact服务器、MySQL数据库。优先级：普通4运行环境需求4.2支持软件客户端支持Android2.2及以上系统。服务器支持Windows2000Server或更新版本；Linux系统。本系统支持的数据库：MySQLServer5.4或更新版本。本系统的开发工具：myeclipse2014（服务器端），eclipse+JDK+SDK+ADT（客户端）。优先级：普通4运行环境需求4.3接口需求无4.4控制需求人工运行软件，无其他特殊的控制信号。优先级：普通5其他需求5.1输入输出需求软件对数据的输入均进行数据有效性检查，除了明确指明的打印
169、输出外，系统不考虑打印输出。优先级：普通5.2数据管理能力需求数据库方面关于菜单、订单、用户的表信息可以定时备份。优先级：普通5其他需求5.3故障处理需求在输入不符合定义格式的数据时，软件应出现提示信息，而不是死机或是删除已经输入的信息，然后再弹出输入界面重新开始。在服务端没有相应客户端的操作时需要提示用户，在必要时可以自动重启服务器。优先级:普通5其他需求5.4界面需求前台客户端用户登陆、注册的界面简约、时尚；点餐主界面美观，功能模块清晰有条理。优先级：次要3-4其他需求分析本章主要对需求分析与建模的要点与误区进行了分析，通过理清框架与脉络，确定需求细节以及对其他需求进行分析给出了方法，在此
170、基础可以进行需求文档化工作，我们家在下一章进行介绍。第四章 需求文档化4.1 4.1 需求规格说明文档来源、作需求规格说明文档来源、作用的介绍用的介绍软件需求规格说明活动，就是将需求信息及其软件解决方案进行正式的定义并文档化，并传递给开发人员的需求工程活动。软件需求规格说明文档,是软件需求规格说明活动的文档记录。软件需求规格说明文档，英文全称为Software Requirements Specification，英文缩写为SRS。需求规格说明文档来源、作需求规格说明文档来源、作用的介绍用的介绍1. 1.什么是需求规格说明文档什么是需求规格说明文档需求规格说明文档来源、作需求规格说明文档来源、
171、作用的介绍用的介绍2 2. .产生阶段产生阶段l对业务需求的定义和文档化，形成了前景和范前景和范围文档围文档。l对用户需求的定义和文档化形成了用户需求文用户需求文档档，其中以用例说明文档用例说明文档最为常见。l在得到用户需求后，需求工程师对其建模和分析，细化为系统需求，并建立满足系统需求的解决方案。对系统需求、解决方案的定义和文档化产生了系统需求规格说明文档系统需求规格说明文档。需求规格说明文档来源、作需求规格说明文档来源、作用的介绍用的介绍需求规格说明文档来源、作需求规格说明文档来源、作用的介绍用的介绍3 3. .作用作用 软件需求规格说明文档是整个开发工作的整个开发工作的整个开发工作的整个
172、开发工作的基础基础，包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规等说明，为软件开发工作提供了依据依据，也为用户、开发人员的理解和交流提供依据依据，同时，在文档反映了用户问题的结构，可作为确认测试和验收的依据依据。需求规格说明文档来源、作需求规格说明文档来源、作用的介绍用的介绍4 4. .需求规格说明活动过程需求规格说明活动过程 需求规格说明活动过程可表示为四步。第一，选择文档模板；第二，裁剪文档模板；第三，文档写作；第四，产生软件需求规格说明文档。需求规格说明文档来源、作需求规格说明文档来源、作用的介绍用的介绍5. 5.文档编写目的文档编写目的 帮助记
173、忆。 帮助发现需求存在的问题。 记录系统解决方案。 为后续活动的依据。 为协议基准。 感谢聆听2016第四章 需求文档化4.2 4.2 文档模板的选择与裁文档模板的选择与裁剪剪1 1 标准模板标准模板文档模板的选择与文档模板的选择与裁剪裁剪1.1 目的1.2 范围1.3 定义、首字母缩写和缩略语1.4 参考文献1.5 文档组织2.1 产品前景2.2 产品功能2.3 用户特征2.4 约束2.5 假设和依赖3.1 对外接口需求3.1.1 用户界面3.1.2 硬件接口3.1.3 软件接口3.1.4 通信接口3.2 功能需求3.2.1 系统特性13.2.1.1 特性描述3.2.1.2 刺激/响应序列3
174、.2.1.3 相关功能需求3.2.1.3.1功能需求1.13.2.1.3.n功能需求1.n3.2.2 系统特性23.2.m 系统特性m3.3 性能需求3.4 约束3.5 质量属性3.6 其他需求附录索引2 2 裁剪模板裁剪模板文档模板的选择与文档模板的选择与裁剪裁剪1. 引言1.1 目的1.2 文档约定1.3 读者对象和阅读建议1.4 项目范围1.5 参考文献2. 总体描述2.1 产品前景2.2 产品特性2.3 用户类及其特征2.4 运行环境2.5 设计和实现上的约束2.6 用户文档3. 系统特性3.1 系统特性X3.x.1 描述和优先级3.x.1 刺激/响应序列3.x.3 功能需求3.2.2
175、 4. 对外接口需求4.1 用户界面4.2 硬件接口4.3 软件接口4.4 通信接口5. 其他非功能需求5.1 性能需求5.2 安全性需求5.3 软件质量属性6. 其他需求附录A： 术语表附录B： 分析模型附录C： 待确定问题清单适当合理修适当合理修适当合理修适当合理修改模板每一改模板每一改模板每一改模板每一部分部分部分部分也可以其他部分不也可以其他部分不动，第动，第3 3部分内容部分内容详细需求描述变动详细需求描述变动下。下。文档模板的选择与文档模板的选择与裁剪裁剪3. 详细需求描述 3.1 对外接口需求3.1.1 用户界面3.1.2 硬件接口3.1.3 软件接口3.1.4 通信接口3.2
176、功能需求3.2.1 模式13.2.1.1 功能需求1.13.2.1.n 功能需求1.n3.2.2 模式23.2.m 模式m3.2.m.1 功能需求m.13.2.m.n 功能需求m.n3.3 性能需求3.4 约束3.5 质量属性3.6 其他需求感谢聆听第四章 需求文档化4.3 文档模板内容撰写的说明合理安排表述相应部分的合理安排表述相应部分的合理安排表述相应部分的合理安排表述相应部分的内容。具体见相关资料。内容。具体见相关资料。内容。具体见相关资料。内容。具体见相关资料。 感谢聆听第四章 需求文档化4.4 4.4 文档的写作文档的写作文 档 的 写 作4.4.14.4.1写作注意事项写作注意事项
177、1.明确文档编写目的。2.按照写作模板写作。3.格式规范文 档 的 写 作4.4.14.4.1写作注意事项写作注意事项1.明确文档编写目的。 编写需求规格说明文档的目的是为了涉众和开发人员之间需求和解决方案的交流。明确文档编写目的，以准确性、完整性为前提，不能随便发挥，应实事求是按照前期需求的获取和分析为第一手材料开展。文档为软件开发过程的第一阶段，是需求工程阶段的标志性文档，是需求工程阶段的成果，为多方后续工作开展的基础，应照顾到多方的理解问题，书写要简介、明确、细化、确定、前后统一不矛盾、完整。文 档 的 写 作4.4.14.4.1写作注意事项写作注意事项2.按照写作模板写作。 写作的内容
178、按照写作模板，适当增删，应完整地体现系统的需求。文 档 的 写 作4.4.14.4.1写作注意事项写作注意事项3.格式规范 文档中图表格式应规范，严格按照相应的制图制表标准实施。用词应严谨。需求不清楚的地方一定要弄清楚后写作，或者做好不清楚的标记，以使需求明确，确定。用直叙的口气，不用惊叹号或问号，不能使用夸大的语言。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点1.完整性2.一致性3.可修改性4.可跟踪性5.可阅读性6.可维护性7.无二义性文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点1.完整性 不能遗漏任何必要的需求信息，需求本身是要完整的，
179、而软件需求规格说明文档也要完整地表述需求。需求规格说明应涵盖需求的全部信息，不能遗漏任何必要的需求信息，业务需求、用户需求、功能需求在需求规格说明书中都有对应的文档信息，每部分内容要完整充分，不同层次需求相互衔接对应。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点2.一致性 一致性是指规格说明中的需求与其他软件需求或高层（系统、业务）需求不相矛盾，在开发系统要解决需求间不一致的或有冲突矛盾的地方，要充分调查研究实际中的需求，确保不同层次需求的一致性。需求之间要不相矛盾，在文档的字里行间也要保持一致。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点3
180、.可修改性需求会因为各种原因而发生变化，这是无可奈何的现实，需求文档总是体现需求，因此需求文档必须是可以被修改的。在必要时或为维护每一条需求变更记录时，应该修改需求规格说明。这就要求每项需求独立标记，并与别的需求区别开来，避免二义性，每项需求在需求规格说明中只能出现一次。这样更改时能够保证需求信息的一直性，另外，应采用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改，同时，这样标记也将修改地方显示清晰。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点4.可跟踪性 需求要保证其可跟踪性，在每项软件需求与它的来源，它的设计、源代码、测试用例之间建立连接链，这种可跟
181、踪性要求每项需求以一种结构化的，粒度好的方式编写并单独表明，这样清晰跟踪需求变化，便于需求变更管理。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点5.可阅读性 一般说来，第一眼看去版面规整、长度适当的文档是读者愿意阅读的。再看内容条理清楚、层次分明、能容易抓住重点的文档是读者在初读之后还愿意继续往下读的关键。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点6.可维护性 相同的内容如果无数次的出现并散落在文档各处无疑会给文档的长期更新带来隐患，可维护性，反映在维护文档的人能够很容易的知道应该更新文档的哪些地方并且如何根据实际需要去更新。例如：使用相同
182、的语句格式来描述所有的细节需求。使用表来组织独立、并列的信息。使用编号来表达繁杂信息之间的关系。可以对图和表进行编号，对文档的章节进行编号，对需求进行标识和编号，并生成相应的目录或索引。文 档 的 写 作4.4.2 4.4.2 文档写作的特点文档写作的特点7.无二义性文字的魅力在于丰富多样，而文字的挑战同样在这里，如何让读的人接收到写的人想要交代的信息，不多不少刚刚好，是一个很大的难题。例如：放弃美丽的女人让人心碎。有多重理解方式。这样的文字表述就不应出现在SRS文档中。第四章 需求文档化4.5 4.5 案例示范案例示范案例示范Android点餐系统需求规格说明文档，采用标准模板，适当增删相应
183、模板内容，文档全文见本节文档资料： 4.5案例-软件需求规格说明文档。案例示范案例案例1 1 从某商店管理系统SRS文档中节选的片段，如图，指出该文档片段的问题。1.1对外接口需求1.1.1用户界面销售处理：系统应该使用Form风格的界面，帮助收银员使用销售处理界面完成商品销售任务。界面图示为【界面表现可以自行定制】 在收银员输入开始销售（快捷键*）命令时，系统应该展开销售列表界面，如图 在销售列表为空时，如果收银员输入会员识别（快捷键）命令，系统显示会员识别界面，如图 在收银员完成输入（快捷键Enter）时，如果系统无法识别会员，显示错误信息，如图案例示范分析：分析：需求没有相应的编号，也没
184、有体现层次结构，文档的可阅读性和可维护性差。可以修改为：如图1.1对外接口需求1.1.1用户界面UI1 销售处理：系统应该使用Form风格的界面，帮助收银员使用销售处理界面完成商品销售任务。界面图示为【界面表现可以自行定制】UI1.1 在收银员输入开始销售（快捷键*）命令时，系统应该展开销售列表界面，如图UI1.1.1 在销售列表为空时，如果收银员输入会员识别（快捷键）命令，系统显示会员识别界面，如图UI1.1.1.1 在收银员完成输入（快捷键Enter）时，如果系统无法识别会员，显示错误信息，如图案例示范案例案例2 2 从某商店管理系统SRS文档中节选的片段，如图，指出该文档片段的问题。3.
185、2.3退货3.2.3.1特性描述在顾客要求退货时，收银员可以进行退货处理。优先级=高案例示范分析：分析：退货 特性描述过于简洁不清楚。在实际业务过程中，容易造成不同收银员间处理标准不一，造成数据混乱，也可能导致顾客和商店间矛盾。文档的表述 应清晰，可阅读性强，且无二义性。可以修改为：3.2.3退货3.2.3.1特性描述 在顾客携带购买收据和退货商品到达收银台并要求退货时，一个经过验证的收银员可以进行退货处理，录入销售记录号，查询销售商品清单，接受退货商品，重新计算账单并退款，还要回收一些赠品。系统最后要更新库存，打印退货留存单据并由顾客签字。 优先级=高案例示范案例案例3 3 从某商店管理系统
186、SRS文档中节选的片段，如图，指出该文档片段的问题。3.3.2可维护性Modifiability1：在系统的商品标识数据格式发生变化时（见Format1），系统要能够快速完成；Modifiability2：如果系统要增加新的特价和赠送类型（例如每天分时段、购买计数等等），要能够相对快完成。Modifiability3：如果系统要增加新的会员服务，要能够在0.25个人月内完成。案例示范分析：分析：可维护性 描述模糊，例如“系统要能够快速完成”，快速是多快？“要能够相对快完成”，相对快是多快？非功能性需求的描述一定要注意数据的准确性或给定数据范围。可以修改为：3.3.2可维护性Modifiabil
187、ity1：在系统的商品标识数据格式发生变化时（见Format1），系统要能够在3人1天内完成；Modifiability2：如果系统要增加新的特价和赠送类型（例如每天分时段、购买计数等等），要能够在0.25个人月内完成。Modifiability3：如果系统要增加新的会员服务，要能够在0.25个人月内完成。感谢聆听第五章需 求 验 证目录5.1需求的验证及过程5.2需求验证的方法及特点5.1.1什么是需求验证5.1 需求的验证及验证过程需求验证是需求工程过程中发生的验证活动，主要观察需求是否正确和充分地表达了涉众的需要。需求验证要确保需求的正确性、完备性、一致性。要确保需求的技术可行性。（图片
188、上字改成正确性、完备性、一致性、可行性）需求验证的目的在于发现错误的数据并进行更改，使软件需求规格说明书达到结构严谨（一致性、简洁、完整）、逻辑完备（包含所有必备的知识）、语义正确（所定义概念、关系及公理或约束与领域知识相符）等要求。5.1 需求的验证5.1.1什么是需求验证？需求验证如何验证软件需求规格说明文档中的非功能性需求呢？5.1 需求的验证5.1.1什么是需求验证如何对软件的质量属性进行区分呢？一种方法是把在运行时可识别的特性与那些不可识别的特性区分开，另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。那些对开发者具有重要意义的属性使产品易于更改、验证，
189、并易于移植到新的平台上，从而可以间接地满足客户的需要。非功能性需求5.1 需求的验证5.1.2系统验证系统验证，指对建立系统的每个过程进行验证，包括需求验证、体系结构设计验证、详细设计验证、代码验证、测试阶段的验证、产品维护阶段的验证。所以系统验证的概念比需求验证大得多，它包含需求验证。5.1 需求的验证5.1.3 需求确认需求确认，就是确认每一条需求都是符合用户的真实意愿，确保需求的内容正确性。一般是先进行需求验证，然后对需求确认。5.1 需求的验证5.1.4 系统确认系统确认，指保证系统能够在预期环境下正确执行相应功能，满足和达到客户需要。需求验证是需求阶段的活动，为系统的实现打下良好的基
190、础。系统确认是系统实现过程的活动，是为了保证系统满足客户要求。需求验证的过程明白需求验证是什么后就可开展需求验证了。需求验证的过程，就是在软件需求规格说明文档完成后，对文档采用相应的验证方法进行验证，发现问题，并提出修改建议，在问题修正后，继续验证，继续发现问题，同时提出修改建议，重复该过程，直到需求被用户确认。感谢聆 听第五章第五章需 求 验 证目录5.1需求的验证及过程5.2需求验证的方法及特点5.2 需求验证的方法及特点 5.2.1 需求评审1.正式与非正式技术评审2.需求审查过程3.进入和退出审查的标准4.需求审查清单5.需求评审的困难5.2 需求验证的方法5.2.1 需求评审1.正式
191、与非正式技术评审非正式评审的方法包括把工作产品分发给许多其它的开发人员粗略看一看，走过场似地检查一遍。5.2 需求验证的方法5.2.1 需求评审1.正式与非正式技术评审正式技术评审，叫作审查（inspection）（Ebenau and Strauss 1994; Gilb andGraham 1993）。正式评审内容需要。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。如果认为没有时间详细审查每个方面，那么可以使用简单的风险分析模型，来区分需求文档哪些部分是需要详细审查的，哪些不重要部分只要用非正式评审就能满足质量要求。5.2 需求验证的方法5.2.1 需求评
192、审2.需求审查过程参与评审的人员参与评审的人员，包括产品的开发者，以及可能的同组成员，包括先前产品的开发者或正在评审的项目的规格说明编写者，包括要根据正在审查的文档来开展工作的人们。很可能参与评审的人员包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员。他们的工作基础都是软件需求规格说明。这些审查人员将会发现不同类型的问题。审查组中的审查人员应限制在7个人左右或者更少。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程审查每个成员扮演的角色 作者：作者创建或维护正在被审查的产品。 调解者：调解者（moderator）或者审查主持者所做的是与作者一起为审查制订计划协调各种
193、活动，并且推进审查会的进行。 读者：读者的角色由审查员扮演。 记录员：记录员或书记员用标准化的形式记录在审查会中提出的问题和缺陷。记录员必须仔细审查所写的材料以确保记录的正确性。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程评审过程 规划（Planning）：作者和调解者协同对审查进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会。 总体会议（overview meeting）：总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。 5.2 需求验证的方法5.2.1 需求评审2.需求审查过程评审
194、过程 准备（Preparation）：在正式审查的准备阶段，每个审查员以典型缺陷为清单，检查产品可能出现的错误并提出问题。审查会议（Inspection meeting）：在审查会进行过程中，读者通过软件需求规格说明指导审查小组一次解释一个需求。当审查员提出可能的错误或其它问题时记录员就记录这些内容，其形式可以成为需求作者的工作项列表。会议的目的是尽可能多地发现需求规格说明中的重大缺陷。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程 重写(rework):几乎每一个质量控制活动都可能发现一些需求缺陷。因此作者必须在审查会之后安排一段时间重写文档。 重审(follow-up):这是审
195、查工作的最后一步调解者或指派人单独重审由作者重写的需求规格说明。重审确保了所有提出的问题都能得到解决，并且正确修改了需求的错误。重审结束了审查的全过程，并且可以使调解者做出判断是否已满足审查的退出标准。5.2 需求验证的方法5.2.1 需求评审3.进入和退出审查的标准一般，需求文档进入审查的标准有：文档符合标准模板，文档已经做过拼写检查和语法检查，作者已经检查了文档在版面安排上所存在的错误，已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明，在文档中打印了行序号以方便在审查中对特定位置的查阅，所有未解决的问题都被标记为TBD待确定，包括文档中使用到的术语词汇表。一般，需求文档退出审查
196、的标准有：已经明确阐述了审查员提出的所有问题，已经正确修改了文档，修订过的文档已经进行了拼写检查和语法检查，所有TBD的问题已经全部解决或者已经记录下每个待确定问题的解决过程、目标、日期和提出问题的人，文档已经登记入项目的配置管理系统，已将审查过的资料送到有关收集处5.2 需求验证的方法5.2.1 需求评审4.需求审查清单（对应图片模糊化处理，不用看到上面具体内容） 为了使审查员警惕审查的产品中的习惯性错误，需对所创建的每一类型的需求文档建立一份清单。清单可以提醒审查员以前经常发生的需求问题。5.2 需求验证的方法5.2.1 需求评审5.需求评审的困难需求评审可能存在各种困难。大型的需求文档，
197、需要庞大的审查小组，需要确保每个参与者都是为了寻找错误，而不是为了解软件需求规格说明中的内容，或者为了维护行政上的位置。需要理解审查员如客户、开发者或测试者所代表的观点，并且委婉地拒绝以相同的观点看待问题的参与者。需要把审查组分成若干小组并行地审查软件需求规格说明，并把发现的错误集中起来，剔除重复的部分。有时审查员在地域上的分散，也造成需求评审的困难。5.2 需求验证的方法5.2.2 原型法首先，确定合适原型，准备需求验证。接着，将需求验证涉及的复杂过程或场景定义出来，以辅助需求验证过程的开展。最后，根据已定义过程和场景，按照原型执行过程，发现需求的缺陷、问题并记录，以待后续修正。5.2 需求
198、验证的方法5.2.3 测试用例开发1.需求测试举例：“Android点餐系统”的开发组是如何使用用户场景分析法，把“点餐下单”功能的需求规格说明、分析模型和早期创建的测试用例结合在一起的5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例：“Android点餐系统”的开发组是如何使用用户场景分析法，把“点餐下单”功能的需求规格说明、分析模型和早期创建的测试用例结合在一起的。1）需求规格说明文档中这样描述：用户打开Android点餐系统客户端，登录帐号后进行网上点餐，选择菜品、座位，确定后提交订单，下单完成。5.2 需求验证的方法5.2.3 测试用例开发2）分析模型：例如，建模用户点餐
199、下单顺序图，如图5.2.1：5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第一步:确定基本流和备选流基本流:用户打开客户端登录帐号选择菜品选择座位选择菜品数量下单生成订单备选流1：账户不存在；备选流2：账户密码错误；备选流3：座位已满； 备选流4：菜品数量不足； 备选流5：菜品已卖完；5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第二步:根据基本流和备选流确定场景场景1 成功下单：基本流；场景2 帐号不存在：基本流，备选流1；场景3 帐号密码错误：基本流，备选流2； 场景4座位已满：基本流，备选流3；场景5菜品数量不足：基本流
200、，备选流4；场景6菜品已卖完：基本流，备选流5； 5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第三步：对每个场景生成相应的测试用例对于这6个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面是一种通用格式，其中各行代表各个测试用例，各列代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果，如表5.2.1所示。 5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第三步：对每个场景生成相应的测试
201、用例测试用测试用例例IDID场景场景/ /条件条件帐号帐号 密码密码 座位可选座位可选数量数量菜品数量菜品数量预期结果预期结果1场景1：成功下单 VVVV下单成功2场景2：帐号不存在1n/an/an/a提示帐号不存在3场景3：帐号密码错误（帐号正确，密码错误）V1n/an/a提示帐号密码错误，返回基本流步骤24场景4：座位已满 vv1n/a提示座位已满5场景5：菜品数量不足vv1n/a提示菜品数量不足，显示剩余量6场景6： 菜品已卖完vvv1提示菜品已卖完，请选择其他菜品5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第四步：设计测试数据一旦确定了所有的测试用例
202、，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表5.2.2所示 5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第四步：设计测试数据测试测试用例用例IDID场景场景/ /条条件件帐号帐号 密码密码 座位座位可选可选数量数量菜菜品品数数量量预期结果预期结果 实际结果XD1场景1：成功下单Test001111112010 下单成功，座位可选减少一位，菜品可点数量减少3份下单成功，座位可选减少一位，菜品可点数量减少3份XD2场景2：帐号不存在Test n/
203、an/a n/a提示帐号不存在提示帐号不存在XD3场景3：帐号密码错误（帐号正确，密码错误）Test00123456n/a n/a提示帐号密码错误，返回基本流步骤2提示帐号密码错误，返回基本流步骤2XD4场景4：座位已满Test001111110n/a提示座位已满座位不可选XD5场景5：菜品数量不足Test00111111101提示菜品数量不足，显示剩余量显示菜品数量，不能输入大于菜品剩余量的数字XD6场景6： 菜品已卖完Test00111111100提示菜品已卖完，请选择其他菜品显示菜品数量为0，不能输入菜品数量5.2 需求验证的方法5.2.3 测试用例开发通过测试用例，可以验证需求，并发现
204、需求的缺陷和问题。 5.2 需求验证的方法5.2.4 编制用户手册一般情况下，用户手册是在系统实现完成准备交付用户使用前编写，是为了帮助用户更好地使用系统，解决可能由于系统环境、配置、安装、功能操作不熟悉等原因带来的问题。但是，如果采用编制用户手册的方法来验证需求，则用户手册编制的工作可以在需求工程阶段就开始。5.2 需求验证的方法5.2.5 需求跟踪需求的发展是有前后联系的，需求之间具有可跟踪关系。如果根据系统需求，不能找到前项用户需求和前项业务需求，那么，跟踪关系不存在，也就说明了该系统需求属于非必要需求，或者也可能发现该系统需求根本没存在的必要。同理，如果业务需求不能发现后项用户需求或后
205、项系统需求的跟踪关系，那么说明该业务需求在需求逐步细化的过程中丢失了，也就发现了软件需求规格说明书的不完整性。5.2 需求验证的方法5.2.6 自动化分析自动化分析方法，一般采用形式化语言检查软件需求规格说明书存在的问题。但是由于形式化语言本身对客户具有难理解的特性，所以使用较少，到目前为止，还没有自动化需求验证方法，也没有成熟的、识别并诊断与需求不符的错误数据的方法。如果软件需求规格说明书的问题、缺陷、漏洞、不完整性、不统一性等诸多问题，可以被自动分析后发现，对于人类在需求工程期间的任务将是一个巨大的进步。目前有研究者在这方面努力，以期取得较好的效果。例如已经有一些自动化工具和系统化方法能部
206、分支持需求定义内在的一致性和完备性检查 , 使得软件需求的质量在一定程度上得到了保证, 但需求定义是否准确地反映用户需求的验证在目前还主要依赖于文档评审和原型示范等技术, 缺乏行之有效的系统化方法。5.2 需求验证的方法5.2.7其他方法目前研究需求验证的其他方法也有一些。有博士论文研究网络式软件需求验证的形式化方法，能有效的刻画用户需求的功能属性和非功能属性，有利于提高需求分析阶段的正确性和完整性，降低软件中因为用户需求的不正确而带来的错误以及资源的损失，提高软件开发的效率。有论文提出一个支持需求验证的过程模型(RVPM), 进行形式化描述, 并论述了需求验证过程的几个关键过程和策略。有基于
207、有向生成图的需求验证方法，基于场景的需求验证方法，基于概念化心智模型的软件需求验证，面向领域的软件需求一致性验证方法研究，基于Petri网模型检验的安全关键软件需求验证，等等。这表明科学工作者们正在认真地探索研究，不断推陈出新。 需求验证的特点 需求验证并不是线性单一的，可以多次反复迭代地进行验证。 需求验证一直以来都是软件开发过程中非常重要的一个环节，软件需求的正确性直接影响着后期开发工作中人力、物力和资源的消耗。内容要点回顾：内容要点回顾：5.1 需求的验证及验证过程5.2 需求验证的方法及特点感谢聆 听第五章6.1需求管理概述软件需求一般可分为功能性需求和非功能性需求。功能性需求包括业务
208、需求、用户需求和系统需求。非功能性需求包括性能需求、质量属性、约束、接口需求。软件需求工程包括需求开发和需求管理。软件需求开发包括需求获取、需求分析、需求规格说明和需求验证四个阶段。需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、系统环境等，对任务进行分析，从而开发、捕获和修订用户的需求，以建立良好的沟通渠道和方式。需求分析主要提炼、分析和审查已收集到的需求，为最终用户所看到的系统建立一个概念模型，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足之处，保证需求的完整性和一致性。需求规格说明是指将获取的需求编写成文档，方便在用户、客户或开
209、发人员之间交流需求信息，是整个开发工作的基础。需求验证是需求开发中的最后一个活动，它的首要目的是确保需求及其文档的正确性，即需求正确地反映了用户的真实意图；它的另一个目的是通过检查和修正，保证需求及其文档的完整性和一致性。需求管理是一种用于查找、记录、组织和跟踪需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统变更上达成并保持一致。需求管理主要包括维护需求基线、实现需求跟踪和控制需求变更等阶段。作为需求开发的结果，最终的需求被明确和固定下来并传递给其他的项目成员，该需求集合即为需求基线。需求基线在建立后并非是一成不变的，在产品开发中以及产品使用之后，用户等产品涉众仍然
210、会提出需求的变更，这些变化都要及时、一致的反映到需求基线中。需求跟踪是一种有效的控制手段，它能够在涉众的需求变化中协调系统的演化，保持各项开发工作对需求的一致性，避免软件系统在开发过程或者演化过程中发生与需求基线不一致和偏离的风险越来越大。需求变更控制以可控制的方式进行需求基线中需求的变更处理，包括对变化的评估、协调批准或拒绝、实现和验证，它是以一种可控制的严格的过程方式来执行需求的变更，从在控制产品生命周期成本的同时，还可以提供最高的客户价值和业务价值。需求变更是无法避免的，伴随着软件的整个生命周期，需求管理显得尤为重要，需求管理可以有以下作用：提高需求开发的准确性提高项目生产率增进涉众之间
211、交流，减少误解和交流偏差准确反映项目的状况，有助于项目管理6.2需求基线6.2.1需求基线的定义需求基线的定义为：已经通过正式评审和批准的规格说明或产品，可作为进一步开发的基础，而且只有通过正式的变更控制过程才能修改它。需求基线是需求开发过程的成果总结，它在整个软件开发周期中发挥作用。需求基线要以一种持续、衡定和易于项目涉众访问的方式存在。需求基线通常以文档的方式纳入配置管理中。需求基线在建立之后，并非是一成不变的。在整个产品开发过程中，用户、客户等涉众人员可能请求需求变更，这些变更要受到控制，并且合理的变更需要及时、一致地反映到需求基线中。6.2.2需求基线的内容软件需求是需求基线的关键内容
212、，但是需求基线所应该包含的内容却不仅仅是软件需求自身，还要包括很多和软件需求相关的描述信息，它们将为软件需求的作用在项目中的有效发挥提供信息支持。(1) 标识符（ID），为后继的项目工作提供一个共同的交流参照。(2) 当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础之上。(3) 源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求的源头。(4) 理由(Rational)，提供需求产生的背景知识。(5) 优先级(Priority)，后续的项目工作可以参照优先级进行安排和调度。(6) 状态(Statuw)，交流和具体需求相关的项目工作情况。(7) 成本
213、、工作量、风险和可变性（Cost、Effort、Risk、Volatility），为需求的设计和实现提供参考信息，驱动设计和实现工作。除了上述的信息之外，其他常用的需求描述信息还有：（1）需求创建的日期。（2）和需求相关的项目工作人员，包括需求的作者、设计者、实现者、测试者等。（3）需求涉及的子系统。（4）需求涉及的产品版本号。（5）需求的验收和验证标准。需求基线的维护6.3需求跟踪6.3.1需求跟踪概述需求跟踪是需求管理的一项重要内容。需求跟踪的主要意义在于获得需求目前的实现状态，确保用户所有的需求都得到满足，它的主要目标是维护软件工作产品间的一致性。需求跟踪是指跟踪一个需求使用期限的全过程
214、，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件等。需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力，是一种有效的控制手段，能够在涉众的需求变化中协调系统的演化，保持各项开发工作对需求的一致性。6.3.2需求跟踪的方式 需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。它分为前向跟踪和后向跟踪两种方式。1.前向跟踪前向跟踪是指需求在被定义到软件需求规格说明文档之前的演化过程，它包括向前跟踪到需求和从需求向后回溯两种联系。向前跟踪到需求：说明涉众的需要和目标产
215、生了哪些软件需求。这样，一方面可以确定是否软件需求规格说明文档的内容完备地体现了所有的涉众需要和目标；另一方面，如果在项目开发过程中或者开发结束后，涉众提出需要、目标或者技术设想的变化就能够快速地确定需要做出改变的相关需求。从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标。这种联系可以帮助找到软件需求的源头，发现不必要的需求，而且，在涉及软件需求的变更时，还可以利用这种联系进行需求变化的验证与确认。2.后向跟踪后向跟踪是指需求在被定义到软件需求规格说明文档之后的演化过程，它包括从需求向前跟踪和回溯到需求跟踪两种联系。从需求向前跟踪：说明软件需求是如何被后续的开发物件支持和实现的。这种联系
216、可以帮助确定软件需求所要求的全部职责都被正确地分配给相应的系统组件。在需求发生变化时，这种联系也可以帮助评估变化的影响范围。回溯到需求跟踪：说明各种系统开发的物件被开发的原因。这种联系可以帮助发现开发工作中的镀金行为。而且在对具体开发物件进行验证或者改变时，这种联系所反映出来的原因也应该是一种重要的参考。6.3.3需求跟踪的必要性需求跟踪是对项目中需求知识的统一化管理和使用。忽视需求的跟踪性，或者对跟踪关系捕捉的不充分会降低系统的质量，引起返工，增加项目的成本和时间。需求跟踪提供了一个表明与合同或说明一致的方法。需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。6.3.4需求跟踪跟踪
217、能力（联系）链需求跟踪能力（联系）链（TraceabilityLink）能跟踪一个需求使用期限（即从需求源到实现的前后生存期）的全过程。跟踪能力是优秀需求规格说明书的一个特征。为了实现可跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。需求可跟踪能力大致可分为四类。从系统需求回溯相应的客户需求，确认每个需求的源头。从客户需求可追溯到系统需求，这样就能区分出开发过程中或开发结束后由于变更受到影响的需求。这也确保了需求规格说明书包括所有客户需求。从系统需求追溯到产品。这种联系链指向了每个需求对应的产品部件，从而确保产品部件满足每个需求。从产品部件回溯到系统需求，表明每个部件存在的原因。6
218、.3.5需求跟踪常用方法需求跟踪的实现方法主要有跟踪矩阵、实体联系模型和交叉引用三种。需求跟踪矩阵是最为常用的实现方法。1.需求跟踪矩阵 需求跟踪矩阵（Requirements Traceability Matrix， RTM）是需求跟踪最为常用的实现方法。它的优点是，跟踪信息清晰易懂，但限于矩阵的二维性，它仅仅能表达二元的跟踪关系。在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助需求跟踪矩阵，则发生上述变更时，往往会遗漏某些连锁变化。需求跟踪矩阵也是验证需求是否得到了实现的有效工具，借助需求跟踪矩阵，可以跟踪每
219、个需求的状态：是否设计了，是否实现了，是否测试了。需求跟踪矩阵并没有规定的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。2.需求跟踪矩阵分类 需求跟踪矩阵，根据跟踪方式可以分为纵向跟踪矩阵和横向跟踪矩阵两类。(1)纵向跟踪矩阵纵向跟踪矩阵，也即生命周期内的跟踪，从其最初的来源（如客户需求等），通过不同层次的工作分解结构得以实现同样的内容，并最终交付给客户的过程。在需求被很好的管理的情况下，跟踪性可以通过从初始需求对应到低级别需求，以及从低级别的需求回溯到其根源来建立。这样的双向可追溯性有助于确定所有初始需求已完全实现，并且所有
220、较低级别的需求可以追溯到一个有效的来源上。(2)横向跟踪矩阵通过识别相关的工作组、产品组件的关系来避免潜在的冲突。这使项目可以在集成测试之前预计可能出现的问题（并且减轻或解决这些问题）。例如，同一个产品的两个相关部件，由两个工作组根据同一份需求分别负责。当一个组件对应的需求发生改变时，可能会影响到另一个组件。横跨两个组件的需求跟踪就能及时发现、规避或解决这些问题。纵向跟踪矩阵是最普遍的一种跟踪方式，也是CMMI进行需求跟踪的最低要求。如表所示，各列中应包括对用户需求、软件需求和概要设计的跟踪，即从需求到后续各阶段均应填写各需求及其实现的对应编号。对于用户需求说明文档、软件需求规格说明文档和概要
221、设计说明文档等各阶段元素之间一对多或多对多的情况，示例如下：3.跟踪矩阵示例 纵向跟踪矩阵表6.3.1左边列的一行对应右边列的多行 用户需求说明文档软件需求规格说明文档概要设计说明文档基线标识C1R2R2-D3编写日期2002-11-202003-1-202003-6-15 需求编号责任人优先级软件需求编号责任人 优先级设计编号责任人优先级 2.1XX12.1XX13.2XX1 5.1XX23.2XX1 3.3XX26.3需求跟踪横向跟踪矩阵在实践中达成的基本共识是：纵向跟踪是必须的，但是横向跟踪如果不做，则是大部分跟踪的工作就无法实施。横向跟踪矩阵的示例如下表6.3.2所示。6.3需求跟踪横
222、向跟踪矩阵表6.3.2需求代号列的一行对应相关需求和接口列的多行需求代号需求项名称功能描述 相关需求接口1.1订单维护采购订单管理系统中的订单是库存管理系统中的入库单的来源入库单生成模块订单输入接口 4.跟踪能力联系链可能的信息源链的源对象种类链的目的对象种类信息源系统需求用例功能性需求功能性需求功能性需求设计元素功能性需求软件需求功能性需求功能性需求软件体系结构元素其他设计元素代码测试实例系统工程师需求分析员需求分析员软件体系结构（设计）者开发者开发者测试工程师5.需求跟踪矩阵的生命期需求跟踪矩阵的使用贯穿了整个软件开发生命周期。从最开始的需求阶段一直到最后的确认测试阶段，任何对软件工作产品
223、的变更都会影响到需求跟踪矩阵。它能够在软件开发生命周期任何时刻反应各个软件工作产品之间的对应关系，达到有效控制各个软件开发阶段产物，从而控制整个软件开发质量的目的，因此其内容是不断完善的。对于有很多子系统构成的大型软件系统进行跟踪能力管理是一项巨大的工程，但同时也很必要。小结小结需求跟踪是个要求手工操作且劳动强度很大的任务，要求组织提供支持。随着系统开发的进行和维护的执行，要保持关联链信息与实际一致。跟踪能力信息一旦过时，可能再也不会重建它了。由于这些原因，应该正确使用需求跟踪能力。6.4控制需求变更6.4.1需求变更的原因(1) 问题发生了改变(2) 环境发生了变化(3) 需求基线存在缺陷(
224、4) 用户变动(5) 用户对软件的认识变化(6) 相关产品的出现问题改变问题改变相关产品出现相关产品出现需求变需求变更更用用户户认认识识变变化化基线存在缺陷基线存在缺陷环环境境变变化化用户变动用户变动6.4.2需求变更的应对策略在需求开发之后冻结需求是不恰当的做法正确的做法是在形成需求基线之后，进行需求的变更控制。需求变更控制并不是要限制甚至拒绝需求的变化，它是以一种可控制的严格的过程方式来执行需求的变更。通过需求的变更控制，项目负责人可以在面对需求的变化是做出周全的业务决策、这些决策在控制产品生命周期成本的同时，还可以提供更高的客户价值和业务价值。6.4.3变更控制的典型过程变更控制的一个典
225、型过程是：需求的提请者需要以正式的渠道提请需求的变化要求，例如通过双方建立的协商机制，或者通过联系开发人员、项目管理人员、市场人员或者技术支持人员等。提交的需求变化请求都会被交给请求的接受者，可能是以书面形式，也可能会以电子文档的格式。评估需求变化可能带来的影响，项目可能会指定固定的评估人来执行评估。需求变更评估的内容要以正式文档的方式固定下来，并提交给变更控制委员会。变更控制委员会依据需求变更评估的信息作出批准或者拒绝需求变化的决定。经过变更控制委员会批准的变更请求会被通知给所有需要修改工作产品的团队成员，由他们完成变更的修改工作。可能会受到影响的工作产品包括需求文档、设计文档模型、用户界面
226、、代码、测试文档和用户手册等。为了确保变更涉及的各个部门都得到了正确的修改，通常还需要执行验证工作。验证工作完成之后修改者才可以将修改后的产品付诸使用，并重新定义需求基线以反映这一变更。6.4.3变更控制的典型过程变更控制的一个典型过程是：6.4.4需求变更控制过程中的注意事项1.认识到变更的必要性，并为之制订计划项目团队必须认识到系统需求的变更是不可避免的，甚至还是必需的。认识到将会有一定数量的变更发生并为之制定变更控制计划是成功进行变更控制的关键。计划的内容应该包括：(1)定义明确的变更控制过程，建立变更控制的有效渠道。所有的需求变更都应该遵循这一控制过程。如果提交变更请求的过程与此过程不
227、符，则不于考虑。(2)所有提交的需求变更请求都要进行仔细的评估。(3)是否进行变更的决定应该由变更控制委员会统一作出。对于未获批准的变更除可行性研究之外，不应再做其他的设计和实现工作。(4)必须对变更的实现结果进行验证。(5)需求的变化情况要及时的通知到所有会受到影响的项目涉众。6.4.4需求变更控制过程中的注意事项2.维护需求基线升级变更记录(1)要更新需求基线，保证项目涉众可以访问到最新的需求。(2)保留需求变更表单的记录，尤其是对批准或者否决的每一个变更请求的理由都要进行记录。(3)绝不能删除或者修改变更请求的原始文本。需求基线的维护工作可以让所有涉众都能了解需求基线的变更情况，使得团队
228、能够区分已知需求、旧需求、新需求以及曾经被增加、修改或者删除的需求。3.管理范围蔓延在需求变更的过程中，对合理和不可避免的需求变化要进行有效变更，但是对不合理的变更请求也要敢于说不。范围蔓延就是一类最为常见的不合理的需求变化请求。范围蔓延是指在需求基线确定之后，再行大幅度增加新的特性、功能和需求，而且这些新增部分是不符合预期的项目前景或者超出预期的项目范围的。因为超出了原来的预算范围，所以范围蔓延的变更请求会消耗额外的项目资源，使项目失去控制。对范围蔓延的管理，要根据业务目标、产品前景和项目范围，评估每一项提议的新增需求和特性。当然管理范围蔓延并不意味着要绝对拒绝任何的范围蔓延，如果涉及非常重
229、大的业务目标调整和市场机遇变化，也可以考虑进行灵活的应对。4.灵活应对变更请求如果需求变更的请求，尤其是范围蔓延的请求对项目的影响过于重大，原则上是需要拒绝的。但是如果变化的要求对客户意义重大，可以为他们取得巨大的利益，那么拒绝的做法也未必正确。在此情况下，一个更加灵活的做法是和客户重新协商原先的项目协定，可能包括：(1)推迟产品的交付时间。(2)要求增派人手，当然这个做法只在有限的情况下有效，因为很多情况下，增加人手只会使得项目更加落后。(3)要求员工加班工作，一段时期的加班会耗尽员工的储备精力，加班不能是长期的工作状态，一般以三十天为限，否则会产生很多消极影响。因此这个做法只能适度使用。(4)推迟或者去除尚未实现的优先级较低的需求。(5)容许产品质量的降低，当然这个做法是最不提倡的，因为低质量的产品会伤害整个开发团队。所以，除非其他的做法都不能达到效果，否则不要使用这种做法。(6)使用辅助工具。 但工具应该具有以下几个特性，以支持需求变更过程： 可用定义变更请求中的数据项。 可用辅助项目涉众完成变更控制过程的协作。 可以帮助维护需求基线，审计变更记录。 能够将变更情况及时的通知到相关人员。 可以生成标准和定制的报告和图表。6.5本章小结了解软件需求管理在软件项目管理中的作用与重要性。熟悉软件需求管理的基本概念、特点和过程。熟悉软件需求管理的基本方法。
