软件需求第2课 软件需求基础(第1版)ppt课件.ppt

第 2 章 软件需求基础,本课主要讨论问题,1 软件需求的基础理论与应用实践,2 需求工程解析,本课主要讨论问题,1 软件需求的基础理论与应用实践,2 需求工程解析,软件需求的基础理论与应用实践,需求的层次,需求的种类,良好的软件需求应该具备的特质,1 软件需求的基础理论与应用实践,导言：什么是软件需求，根据调查，许多软件开发人员认为：软件需求就是用户需要实现的功能加上一些非功能方面的需求。上述的理解并不完善。如果对用户所处的业务环境没有建立正确的认识，经常会给我们的工作带来巨大的麻烦。,1 软件需求的基础理论与应用实践,IEEE(美国电气电子工程师学会)软件工程标准词汇表（1997年）将需求定义为：（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。 上述标准的定义说明了三个方面的问题：从用户的角度来看，需求是什么？（1）从软件开发者的角度来来看，需求是什么？（2） 需求最终以 何种形式反映出来？（3） 需求就是以一种清晰、简洁、一致且无二义性的方式对一个待开发系统中各个有意义陈述方面的一个集合。,1 软件需求的基础理论与应用实践,对软件需求的理解 需求定义了系统必须具备的能力，这种能力体现了用户的需要和开发者对用户需要的理解。并且通过文档，以标准的语言标明这些需要的确切含义。将这些系统按照一定的规范记录下来、组织起来、以便跟踪他们的变更。,1 软件需求的基础理论与应用实践,从实践的角度来看，软件需求一般可以定义为：软件需求包含业务知识、问题列表和其他相关因素。,业务知识：业务事件、业务实体、业务规则；问题列表：用户在工作中遇到的困难和障碍 (软件开发时需要解决的问题)；其他相关因素：设计约束和非功能方面的需求。,对软件需求的理解,1 软件需求的基础理论与应用实践,在实际工作中，编写需求规格说明书是常常会看到一下几个名词：业务需求、软件需求、用户需求。实际上上述名词反映了需求的三个层次。,需求的层次,1 软件需求的基础理论与应用实践,需求的三个层次及关系,业务需求,业务需求反映企业/组织对软件系统的高层次目标需求，也就是说是软件需求的建设目标。通常这一目标体现在两个方面。 问题：解决企业/组织运作过程中遇到的问题，例如销售下降、物质供应问题、用户投诉、客户流失率居高不下等。 机会：抓住外部环境变化（业务、技术）所带来的机会，以便为企业带来新的发展，例如电子商务，网上银行、协同工作等。,1 软件需求的基础理论与应用实践,系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）,软件需求的三个层次及关系,业务需求理解,1 软件需求的基础理论与应用实践,软件需求的三个层次及关系,业务需求作用意义,业务需求的提出人通常是企业/组织的高层管理人员。业务需求是彻底从业务角度描述的，是指导软件开发的高层需求。明确地定义业务需求，将给整个团队指出努力的方向，这对整个开发活动将有积极的意义,业务需求建立的时间,业务需求往往是在项目立项阶段整理完成 的，通常体现在战略规划报告，或者立项建议报告中。,1 软件需求的基础理论与应用实践,软件的生存周期,问题定义,可行性研究,需求分析,软件设计,编码,测试,维护,计划时期,开发时期,运行时期,业务需求-高层次需求,1 软件需求的基础理论与应用实践,问题与机会,业务需求,实例1-广东地税业务需求,1 软件需求的基础理论与应用实践,实例1-广东地税业务需求,广东地税业务战略要点,1 依法治税2 为纳税人服务3 加强内部监控，促进廉政建设4 增强税收系统的决策支持能力5 降低税收成本，提高税收工作效率,在目前税收环境尚不完善，纳税人的纳税意识有待加强的实际情况下，有必要在依托现代信息系统的基础上加强对税源的监控，为真正的应收尽收、依法征税打下基础，也为稽查工作提供数据来源。值得指出的是，依法治税也意味着稽查工作在相当长一段时间内仍然是税务机关的工作重点。,从税务机关的角度看，纳税人的权益包括透明的税法信息、方便的咨询服务、多渠道纳税服务、多手段纳税信息的查询等。这一切更应该以及时、公开的方式向纳税人公布，并结合各方意见定期更新,除了加强内部监督与廉政教育之外，更重要的是从制度上和管理手段上尽可能地减少税收执法的随意性以及滥用权力现象的发生。采取征、管、查分离的方式。内部监控的加强往往涉及机构与岗位职能、职业操守准则、考核机制、业务流程、信息系统等多方面的因素，只有综合采用多种管理手段，才能收到好的效果。,完整、准确的税收信息对确定税收工作的重点、合理调配资源等决策工作有着非常重要的作用。在反映经济运行状况的各类数据中，税收数据是最为及时、也是相对全面和准确的信息资源，长期以来一直受到政府有关部门的高度重视。税务部门应努力提高税收数据的质量，并深入开展分析和研究工作，为政府宏观经济决策提供更有力的支持。目前全国税务系统在提供准确、及时的税收数据，支持决策方面的能力还很有限。应率先作出有益的积极尝试，让税收信息能够真正为管理和决策提供服务。,纳税成本对政府税收政策的制定有重要影响，因此有必要考虑试行收集有关数据，建立相应系统来核算纳税成本、以便为决策支持提供依据，这同时也是为纳税人服务的另一种体现。针对税收工作的效率，仍有很大潜力可挖。如：通过信息技术手段而实现更智能化的稽查选案、更多的申报和缴纳渠道、更快速准确的税收统计分析等,1 软件需求的基础理论与应用实践,需求的三个层次及关系,用户需求,用户需求是指描述用户使用软件需要完成什么任务，怎么完成的需求。通常是在业务需求定义的基础上通过用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求捕获的结果。,1 软件需求的基础理论与应用实践,需求的三个层次及关系,用户需求的理解,执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么直接用户间接用户 对所有的用户需求，都应该有充分的问题域知识作为背景支持。,用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求的描述原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。问题：自然语言表达容易含糊和不准确。,1 软件需求的基础理论与应用实践,需求的三个层次及关系,用户需求的理解,实例2：图书馆用户需求用户可以通过Internet 随时查询图书信息和个人借阅情况，并可以快捷地查找和浏览所需要的电子资料。分析：上述需求描述包含了三个不同的需求用户可以通过Internet 随时查询图书信息。用户可以通过Internet 随时查询个人借阅情况。用户可以通过Internet 快捷地查找和浏览所需要的电子资料。问题：“随时”和“快捷”是对系统功能的约束，十分模糊。,1 软件需求的基础理论与应用实践,需求的三个层次及关系,用户需求的理解,1 软件需求的基础理论与应用实践,需求的三个层次及关系,用户需求的特点,1 零散：用户会提出不同角度、不同层次、不同粒度的需求， 并且通常是以一句话的方式提出的。例如，在电信行业，对 资费快要用完的用户，可以根据用户的要求通过短信方式将 欠费和即将欠费的信息发送给相关用户。2 存在矛盾：由于用户往往处于企业/组织的不同层面，所以难免 会出现盲人摸象的情况，从而导致需求的片面性，甚至在不同用户之间会持有不同的观点。,需要对用户需求进行分析、整理，从而获得比较准确的需求说明,1 软件需求的基础理论与应用实践,需求的三个层次及关系,软件需求（系统需求）,用户对软件系统行为的期望，一系列的行为联系在一起可以帮助用户完成任务，满足业务需求 软件需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么 将用户需求转化为软件需求的过程是一个复杂的过程首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。,1 软件需求的基础理论与应用实践,软件需求（系统需求）,需求的三个层次及关系,如前所描述，业务需求具有高层次，比较抽象。用户需求具有零散、存在矛盾的情况。 需求分析人员需要按照业务需求的基本要求和指导原则，对用户需求进行分析、整理、提炼等工作，从而生成指导开发的、更精确的软件需求。 软件需求是需求分析和建模的产物。,1 软件需求的基础理论与应用实践,需求的三个层次及关系,业务需求是需求定义的产物；用户需求是需求捕获的结果；软件需求是需求分析和建模的综合。,1 软件需求的基础理论与应用实践,需求的三个层次及关系,关系,1 软件需求的基础理论与应用实践,软件需求的三种类型,软件需求可以分为：功能需求、 非功能需求 设计约束,1 软件需求的基础理论与应用实践,软件需求的三种类型,功能需求,功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。实例3：图书馆系统功能需求用户可从图书资料库中查询或选择其中的一个子集。系统可提供适当的浏览器供用户阅读电子文献。用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的帐户上。,1 软件需求的基础理论与应用实践,软件需求的三种类型,功能需求理解,对于功能需求而言，最为关键的是任何对其进行组织，否则一句话、一句话地描述就会显得十分零散，而且难以保证开发人员逐一满足这些需求。 传统的需求开发方法中，通常会以软件系统-子系统-模块-子模块的层次结构来组织。其问题是采用该方法更多地是从程序的结构来梳理需求，问题是可能将用户的使用场景割裂开来。 现代需求理论更强调需求分析人员从用户的角度，将系统理解为一个黑盒子，从使用角度来整理需求，不管是RUP或者是XP 方法都是如此。当然也不是说这样的方式就不存在问题，比如可能存在组织混乱的情况。,功能需求的要点在于如何组织,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求,非功能需求从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。实例4：图书馆系统非功能需求系统应在20 秒之内响应所有的请求。系统每周7 天、每天24 小时都可以使用。对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求,非功能需求可以考虑的组织方式,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求理解,非功能需求常见的问题主要有：信息传递的无效性；忽略了非功能需求的局部性。 信息传递的无效性：许多需求规格说明书中，会通过一个名为设计原则的章节来说明非功能需求，列出诸如高性能、高可靠性、高可用性、高可扩展性等要求。实际应用中，多数开发人员根本就不去考虑这些问题。因为对这样的非功能描述没有判定标准，由此这类传递的信息是无效的。 忽略了非功能需求的局部性：通常可以看到的非功能需求，比如“系统响应时间小于5秒”的描述，但当用户查询的是年度统计数据时，这样的要求根本无法实现。由此开发人员仍然不会将这类问题加以仔细考虑，最终将这些要求变成摆设。,非功能需求一定要注意保证信息的有效传递和注意其局部性,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求理解,一般在软件开发过程中可以将非功能需求划分为： 性能需求，质量属性，对外接口等,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求理解,速度（Speed），系统的响应时间，例如PR2.3.3-1。PR2.3.3-1：所有的用户查询都必须在10秒内完成。容量（Capacity），系统所能存储的数据量，例如PR2.3.3-2。PR2.3.3-2：系统应该能够存储至少10万条销售记录。吞吐量（Throughput），系统在连续的时间内完成的事务数量，例如PR2.3.3-3。PR2.3.3-3：解释器每分钟应该至少解析5000条没有错误的语句。负载（Load），系统可以承载的并发工作量，例如PR2.3.3-4。PR2.3.3-4：系统应该允许200个用户同时进行正常的工作。实时性（Time-Critical），严格的实时要求，例如PR2.3.3-5。PR2.3.3-5：监测到病人异常后，监控器必须在0.5秒内发出警报。,性能需求,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求理解,系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量 质量属性是为了度量质量要素而选用的特征 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系 质量属性的重要性 对设计的影响很大 对越复杂的系统越为重要 Robert19901 ：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要。,质量属性,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求理解,用户并不能明确地提出他们对产品质量的期望并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性需求工程师质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性 形容词和副词通常意味着质量属性的存在 对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在,质量属性的开发,1 软件需求的基础理论与应用实践,软件需求的三种类型,非功能需求理解,解系统和其他系统之间的软硬件接口 接口的用途接口的输入输出数据格式命令格式异常处理要求用户界面 利用专门的人机交互设计文档记录,对外接口,1 软件需求的基础理论与应用实践,软件需求的三种类型,设计约束,一般包括非技术因素决定的技术选型问题，以及预期的软硬件环境，预期的使用环境等。 设计约束非常重要，不要认为是可用可无的。,1 软件需求的基础理论与应用实践,软件需求的三种类型,设计约束的理解,非技术因素决定的技术选型：对于软件开发而言，有些技术不是由技术团队决定的，而是会受到企业/组织实际情况的影响。例如：必须采用具有自主知识产权的数据库系统，系统开发必须使用J2EE技术等。,1 软件需求的基础理论与应用实践,软件需求的三种类型,设计约束的理解,预期的软硬件环境和使用环境：技术开发团队在决定架构、选择实现技术时会受到企业/组织实际的软硬件环境的影响，如果忽略该方面的因素往往会给项目带来不必要的麻烦。,例如：黑龙江省地方税务局征管系统软件系统在省、地（市）、县（区）应用良好。但在所级应用存在问题，主要原因在于所级单位地处边远，电脑配置低、网络速度慢（或者根本没有）。最后不得不专门编写了所级软件。说明需求分析人员在整理需求时，应该将这些预期的软硬件环境都描述完整，最有效的方法是采用部署图方式。,1 软件需求的基础理论与应用实践,需求的三个层次及关系,关系的另外一种角度,1 软件需求的基础理论与应用实践,良好的软件需求应该具备的特质,完整性、真实性、优先级、技术早期介入,1 软件需求的基础理论与应用实践,关于完整性,良好的软件需求应该具备的特质-完整性,需求的完整性简单的说就是需求没有遗漏。其表现为需求变更中新需求所占的比例为零。当然这只是理想情况，一般我们在软件开发工程中需求变更不超过10%就相当不错了。 为什么开发人员最讨厌的事情就是需求变更？增加了工作量，并可能导致以前的开发报废,1 软件需求的基础理论与应用实践,关于完整性,实现完整性的有效方法： 用户才是验证完整性的合适人选； 需求完整性存在不同的层面上。,良好的软件需求应该具备的特质-完整性,1 软件需求的基础理论与应用实践,关于完整性,用户才是验证完整性的合适人选；,需要从业务角度来组织各类需求项，让用户验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤、困难和障碍等是否完整，更具有可操作性。,良好的软件需求应该具备的特质-完整性,1 软件需求的基础理论与应用实践,关于完整性,需求完整性存在不同的层面上。,需求是有层次的，不同的管理人员所了解和掌握的信息是不一样的。在验证需求是需要存取分层评审的方式，让不同层次的人员负责评审自己相关的领域。,业务导向的层次结构是保证需求完整性的关键,良好的软件需求应该具备的特质-完整性,1 软件需求的基础理论与应用实践,关于完整性的理解,需求分析人员就像是在为一个人画像，如果将视角放得太近，想要将人画完整是不可能的。 正确的做法是先后退到适当的距离，把整个轮廓画出来，然后走近一些，将不同的组织部分分解开，最后再走到跟前，将细节画出来。,良好的软件需求应该具备的特质-完整性,1 软件需求的基础理论与应用实践,关于完整性的理解,具体说就是在需求构建时先描述宏观部分（比如确定主题域的划分，并让高层进行验证。分析标识出来的主题域是否能够达到目标所需涉及的范围。然后针对主体域进行分析，找到其流程和实体，让中层对其进行验证；最后走向操作层，对细节进行描述并验证）,在税务行业一般在做需求是都将其划分为：决策层，管理层和操作层。以尽量保证需求的完整性,良好的软件需求应该具备的特质-完整性,1 软件需求的基础理论与应用实践,关于真实性,良好的软件需求应该具备的特质-真实性,需求的正确性和无歧义性是一组相关的要求。指的是确保在信息传递的过程中不失真。,1 软件需求的基础理论与应用实践,关于真实性的理解,良好的软件需求应该具备的特质-真实性,正确性：要使需求确保正确，就需要找到正确的人来验证。分层 验证是可以存取的有效手段。无歧义性：不同背景的人在传递时加入了不同理解而导致歧义。 由此需要建立一些消除歧义性的方法和手段。例如建立 系统术语表等。,强化验证是保证真实性的关键,1 软件需求的基础理论与应用实践,关于优先级,良好的软件需求应该具备的特质-优先级,优先级要分层次。层次的划分一般要从业务角度考虑,1 软件需求的基础理论与应用实践,关于技术早期介入,良好的软件需求应该具备的特质-技术早期介入,需求规格说明书的内容从用户来；需求规格说明书谁看？当然是技术团队。所以在需求规格说明书构建过程中，应该让技术团队了解相关需求，并分析存在什么问题，缺少什么信息等。是改进需求规格说明书的主要方法。,本课主要讨论问题,1 软件需求的基础理论与应用实践,2 需求工程解析,2 软件需求工程解析,需求工程的定义与范畴,需求开发工作要点,需求管理工作要点,2 软件需求工程解析,导言：需求工程,软件工程主要活动包括：需求、系统分析与设计 （概要设计、详细设计）编码、测试、运行与维护等,一般仅将需求称为工程，主要原因在于（如左图）如果在需求阶段只需要花费1个时间单位就能够改正的错误，如果推迟到设计阶段改正就需要5个时间单位，如果推迟到测试阶段就可能达到20-50个时间单位，如果推迟到运行与维护阶段就可能需要花费200个时间单位,2 软件需求工程解析,需求工程的定义与范畴,其实该问题非常好理解。需求阶段毕竟是在纸上谈兵。随着开发阶段的不断深入，产生的人工制品也就不断增多。要进行修改，则需要考虑的东西就越多，代价越大。另外，需求工作是用户需求到技术解决方案的转换，所以被称为“需求工程”,2 软件需求工程解析,需求工程的定义与范畴,需求工程主要包括需求开发和需求管理两个主要范畴。需求开发：收集、分析、整理、编写、验证需求的全过程， 重点在于开发出高质量的需求规格说明书。需求管理：对需求的变化全过程进行跟踪。 重点在于确保开发的软件满足需求的定义。,2 软件需求工程解析,需求工程的定义与范畴,需求开发,需求管理,需求工程,需求获取,需求分析,需求编写,需求验证,基线管理,变更管理,跟踪管理,其 他,2 软件需求工程解析,需求开发工作的要点,需求获取,需求分析,需求验证,需求规格说明书,需求开发过程,2 软件需求工程解析,需求开发工作的要点,现代需求开发的思想更趋向于采用多次循环的方式开展需求开发工作。每次循环（迭代：iteration ）的过程见上图所以。具体对四个阶段的详细讨论将在后续章节中进行。 循环的次数如何确定？根据实际情况来定。 但一般来说可以分为三次循环： 初始循环；脉络循环；细节循环,2 软件需求工程解析,需求开发工作的要点,需求开发的三次迭代,2 软件需求工程解析,需求开发工作的要点,关于需求获取的简单描述,需求获取又称为需求捕获。获取或者是捕获都是主动动词，但实际应用中，需求实践往往是被动的，主要体现在以下几个方面： （1）捕获范围不足：许多需求分析人员认为需求就是用户要实现什么功能，由此在需求捕获时往往不注重对业务知识的捕获，以为业务知识不是系统要做的。表面上是节省了一些时间，代价是后续工作往往以不断变更的形式回报给应用开发团队。,当前，许多大型的应用软件系统开发都需要行业专家的参与。行业专家的主要特点是了解相关行业的业务知识，对业务过程、业务流程等相当熟悉。在系统开发初期，他们比技术人员起到的作用要大。,2 软件需求工程解析,需求开发工作的要点,关于需求获取的简单描述,（2） 缺乏计划性、科学性：捕获过程随意，走过场，预先没有对问题、时间、访谈人员进行计划，造成需求捕获的时间利用率不高；捕获过程相对比较分散，没有做到定向、聚焦、而且经常将宏观问题和微观问题混在一起。例如，了解流程时可能更关注数据细节问题。,当前，许多大型的应用软件系统开发都需要根据行业专家的意见，科学合理的安排捕获流程和捕获程序。,2 软件需求工程解析,需求开发工作的要点,关于需求获取的简单描述,（3） 捕获对象不明确，捕获手段不足。很少主动寻找被访谈者，经常是用户方占据主动。不同场景下、不同的用户层次需要存取不同的需求获取手段。,主动开展需求捕获工作是需求获取阶段的重要策略。,2 软件需求工程解析,需求开发工作的要点,关于需求分析的简单描述,需求分析是需求开发的核心问题，不能直接将需求捕获得到的信息整理到SRS中。需求分析中分析的含义如下描述：,2 软件需求工程解析,需求开发工作的要点,关于需求分析的简单描述,简单说，需求分析就是通过对问题域的研究，获得对该领域特性及其存在于其中的（需要解决）的问题的透彻说明并用文档加以描述和说明。具体说：需求分析是业务分析，需求分析的任务是对问题进行研究，因此将从业务线索入手，而非从系统结构入手。需求分析是分解过程，将待开发的系统按照职责划分为不同的主题域（子系统）然后分解组成该主题域的所有业务流程，再分解到业务活动、业务步骤。需求分析以一种综合的过程，需要将用户的原始需求合并到业务活动中。将各个业务流程合并为全局业务流程图，将各个业务事件相关的领域类图合并成全局领域类图，将各个业务事件的用例图片段合并为全局用例模型等；需求分析是一个规范化活动，要找到冲突、矛盾，并且通过访谈等手段解决这些问题。,2 软件需求工程解析,需求开发工作的要点,关于需求规约的简单描述,需求规约就是将需求分析结果文档化的过程。对于大型软件公司来说，需求文档化的过程是一件大事，需要高度重视（甚至过度重视）。,SRS的管理主要要体现下列思想： 软件需求规格说明书是用来完成信息传递和沟通的，因此必须实现共享； 软件需求规格说明书在整个开发过程中是不断演化的，需要建立良好的更 新机制；,2 软件需求工程解析,需求开发工作的要点,关于需求验证的简单描述,多数软件开发项目都不重视需求验证工作。需求验证是对需求捕获和需求分析的结果（SRS）进行验证的过程。不是简单地让用户代表签个字就完事。因为没有经过需求验证的需求往往存在大量的业务和技术隐患，结果将会导致大量的需求变更。需求验证的主要手段是需求评审。需要分层次、分内容开展，以便能够尽早更多地暴露需求中存在的问题。,2 软件需求工程解析,需求管理工作要点,需求管理工作一般包括基线管理、变更管理和需求跟踪。,需求分析,待处理的需求,变更申请,变更分析,基线管理,需求基线,变更管理,需求跟踪,2 软件需求工程解析,需求管理工作的要点,关于基线管理的简单描述,需求基线的引入，会将需求分为两大类：已经开发的基线内的需求（Baseline）尚未开发的待处理需求（Backlog）。基线的内容就是一次迭代的工作内容。而一次开发迭代是一个时间周期，时间是固定的，相对较短的，RUP建议是2-6周。划分基线时通常需要完成三件工作：确定优先级，确保高优先级、高风险的需求项在尽早的迭代中完成；二是工作量估计，以确保每次迭代的时间安排是合理紧凑的；三是未完成项的合并工作，每次迭代还是有些工作未能完成，在分配下一次基线是需要将其考虑进去。,需求优先级与工作量估计是基线管理的关键,2 软件需求工程解析,需求管理工作的要点,关于变更管理的简单描述,软件开发的过程必然会出现变更。虽然我们总是强调与用户确定需求冻结，但真真的需求冻结往往是不可能的。需求变更管理的核心是控制变更的影响，而非消除变更。控制变更对技术开发工作所带来的影响，减少返工、重做的工作量。变更工作需要整个开发团队相互配合，需求分析的贡献在于“尽早识别变更”，系统架构的贡献在于“以弹性的架构减少变更的影响”,2 软件需求工程解析,需求管理工作的要点,关于需求跟踪的简单描述,对变更的影响进行分析时，就会发现很难精确地评价变更将影响那些需求项，那些设计元素，只能凭经验与印象，而想要真正做到精确地量化评估，就需要通过跟踪需求活动积累的信息。需求跟踪具有相当的难度，一般的项目都未能正真使用它。,本章重点：需求的三个层次及关系,关系,需求开发,需求管理,需求工程,需求获取,需求分析,需求编写,需求验证,基线管理,变更管理,跟踪管理,其 他,本章重点：需求工程的定义与范畴,需求获取,需求分析,需求验证,需求规格说明书,本章重点需求开发过程,