软件需求分析过程

软件需求分析与建模林泉软通动力信息技术（集团）有限公司2011软件工程方法与实践2/150主要问题什么是软件需求？软件需求分析有哪些过程？如何启动分析过程？什么是面向数据的建模？什么是面向数据流的建模？什么是非形式化建模、半形式化建模和形式化建模？什么是统一建模语言（UML）？什么是用例建模？什么是领域模型？3/150软件需求分析过程什么是软件需求？软件需求分析有哪些过程？如何启动分析过程？需求规格文档有哪些内容？需求分析有哪些技术？4/150一般把需求定义为“（正在构建的）系统必须符合的条件或具备的功能或能力”。电气和电子工程师学会使用的定义与此类似。著名的需求工程设计师MerlinDorfman和RichardH.Thayer提出了一个包容且更为精练的定义，它特指软件方面-但不仅仅限于软件：1、软件需求可定义为：用户需解决某一问题或达到某一目标所需的软件功能。2、系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。5.1什么是软件需求5/150需求工程基本任务需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理6/150需求分析的基本任务需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。7/150需求分析模型系统实现模型目标系统当前系统物理模型逻辑模型逻辑模型物理模型模型化抽象化实例化具体化理解需求表达需求导出做什么怎么做需求分析的主要工作系统流程图或高层DFD图DFD图、STD图、E-R图、用例图、类图、顺序图等8/150目标系统描述现实系统是如何在物理上实现的。描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。描述新系统是如何实施的（包括技术）。逻辑模型物理模型(本质模型、概念模型)(实施模型、技术模型)描述重要的业务功能，无论系统是如何实施的。现行系统需求分析模型9/150软件需求曾经让我们如此狼狈10/150软件开发的问题分类0102030405060123456主要问题次要问题不是问题1、需求规格说明4、软件和测试2、管理客户需求5、项目管理3、建档6、编码问题的重要性依次降低ESPITI(欧洲软件过程改进培训倡议）所作的一个调查，3800个被调查者认为，软件开发的主要问题、次要问题和不是问题的问题如图。一半以上的人认为，软件的二个最大问题是：1、需求规格说明2、管理客户需求相对而言，编码不是问题11/150需求错误的代价修复的相对成本需求阶段0.1-0.2设计0.5维护20验收测试5单元测试2编码1“需求开发可能是软件开发中最困难、最关键、最易出错以及最需要沟通的方面”12/150需求变化合理范围内的变化：用户不了解自己的需求需求本身易变，市场、技术、竞争因素不合理的变化：需求文档质量不高需求分析技能、技术和管理上的缺陷需求变化的原因：未受控制的需求变更遗漏需求用户交流不够需求规约质量差低效的需求分析谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。13/150需求分析的重要性需求的重要性：需求是产品的根源，需求工作的优劣对产品影响最大。是系统开发的基础，质量和成败的关键国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。需求分析是通过问题识别、分析与综合、制订规格说明和评审等阶段，达到为系统设计提供依据的目标。因此，需求分析过程包括：确定对系统的综合要求分析系统的数据要求抽象出并确立目标系统的逻辑模型编写需求规格说明书14/150需求分析就是为了实现系统需求，并使最后交付成果与需求所要求的目标不产生：含糊性、不完整性、不可检验性、不一致性、不可追踪性和不可用性。需求分析面向下阶段——系统概要设计需求分析采用自己的特定方法，达到相应的阶段要求采用的方法是尽量地让用户和开发团队都能理解并认同系统目标和范围界定的方法——业务/系统模型、用例和USECASE图需求分析阶段的目标是用计算机的（而不再是用户）眼光和语言，分解需求、定义需求。但是，这个眼光不是程序设计员的眼光，是系统分析师的眼光经过需求处理后，达到需求规范要求分析的方法是一套“建模”技术需求分析的成果15/150软件需求的分类功能需求：描述系统预期提供的功能或服务对系统应提供的服务如何对输入做出反应系统在特定条件下的行为非功能需求：指那些不直接与系统具体功能相关的一类需求产品需求机构需求外部需求领域需求：源于系统的应用领域需求16/150功能需求软件系统的功能需求描述可以有许多方式：文字描述图表表示功能需求可以以不同的详细程度反复编写和细化功能需求描述应该完整而且一致和准确完整性意味着用户所需的所有的服务应该全部给出描述一致性意味着需求描述不能前后矛盾准确性是指需求不能出现模糊和二义性的地方17/150功能需求描述：出卷系统教师能够根据自己的要求手动或自动出一份试卷；教师可以修改试卷中不合适的题目，并能自动生成各种样式的试卷；教师可以对试题中的题目进行更新。18/150非功能需求非功能需求主要与系统的总体特征相关，是一些限制性要求，是对实际使用环境所做的要求性能要求可靠性要求安全性要求可用性要求移植性要求非功能需求关心的是系统整体特征而不是个别的系统的特征，比功能需求对系统更关键。非功能需求却很难检验非功能需求与功能需求有时会发生冲突，它们之间存在着相互作用关系19/150非功能需求举例一个POS系统所需的存储因为成本原因有所限制，而商品的描述和价目表的信息量很大。如果采用远程服务器，提供商品描述和价目表信息，那必然需要网络通信，而这需要网络技术。当POS机数量多时必然引起服务器处理瓶颈问题。20/150领域需求领域需求反映应用领域的基本问题，直接影响到系统的可用性。例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络打印机上，但因为版权限制，这些文档打印之后应立即删除。21/150领域需求示例：短信系统如果短信经过终端无线模块发送之前必须经过短消息协议标准编码才能发送出去。要对短信编码，必须要对由ESTI制订的SMS规范有所了解技术实现(含编码方式)GSM03.38、GSM03.40SMS的DTE-DCE接口标准(AT命令集)：GSM07.05三种方式来发送和接收SMS信息：BlockModeTextMode：纯文本方式，可使用不同的字符集，也可用于发送中文短消息，主要用于欧美地区。PDUMode：PDUMode被所有手机支持，可以使用任何字符集，这也是手机默认的编码方式22/1505.2需求分析过程需求分析过程主要是理解客户需要什么、分析要求、评价可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求以至将这些需求转化为可行系统过程包括：初步沟通导出需求分析和精化可行性研究协商与沟通规格说明需求验证变更管理23/1505.2.1初步沟通业务领域的共利益者（如业务管理人员，市场营销人员，产品管理人员）定义业务用例确定市场的范围初略地可行性分析确定项目范围的工作说明24/1505.2.2导出需求导出需求应理解问题：范围问题：系统的边界，是客户和开发者共同关心的部分理解问题：确定业务需求、需求冲突、说明有歧义和不可测试的需求易变问题：分清需求稳定部分和易变部分收集活动：识别真正的客户/用户正确理解客户的需求耐心听取客户意见和思考尽量使用符合客户语言习惯的表达25/1505.2.3分析和精化开发一个精确的技术模型，用以说明软件的功能、特征和约束。精化是一个分析建模动作，由一系列建模和求精任务构成定义了问题的信息域，功能域和行为域26/1505.2.4可行性研究可行性研究的目的是确定用最小的代价，在尽可能短的时间内确定问题是否能够解决可行性研究的输入是系统的一个框架描述和高层逻辑模型输出是一份需求开发评价报告，对需求工程和系统开发是否值得做的具体建议和意见三个问题：系统是否符合机构的总体要求？系统是否可以在现有的技术条件、预算和时间限制内完成？系统能否把已存在的其他系统集成？27/150可行性研究的任务可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解决。一般来说，至少应该从下述四个方面去研究每种解法的可行性：技术可行性：使用现有的技术能实现这个系统吗？经济可行性：这个系统的经济效益能超过它的开发成本吗？操作可行性：系统的操作方式在这个用户组织内行得通吗？时间可行性：能在预定时间内完成吗？可行性研究最根本的任务是对以后的行动方针提出建议。28/1505.2.5协商与沟通调节冲突和问题需求排序识别和分析与每项需求相关的风险、开发工作量、成本和交付时间29/1505.2.6软件需求规格一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或以上各项的任意组合。软件需求规格（SRS，SoftwareRequirementSpecification）是需求分析任务的最终“产品”，它是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。分为：用户需求和系统需求30/150用户需求描述示例2.1处理销售：完成一次销售过程。2.1.1基本流程：（1）顾客携带所购商品或服务到收银台通过POS机付款；（2）收银员开始一次新的销售交易；（3）收银员输入商品条码；（4）系统逐条记录销售的商品，并显示该商品的描述、价格和累计额；重复（3）—（4），直到输入结束；（5）系统显示总额；（6）收银员告知顾客总额，并请求付款；（7）顾客付款，系统处理支付；（8）系统记录完整的销售信息，并将销售金和支持信息发送到外部的帐务系统和库存系统；（9）系统打印票据；（10）顾客携带商品和票据离开。2.1.2扩展流程：......31/150系统需求系统需求是比用户需求更详细的需求描述，是系统实现的基本依据系统需求描述可能包括许多不同的模型，如对象模型和数据流模型32/150软件需求各组成部分之间的关系33/150软件需求规格说明的原则从现实中分离功能，即描述要“做什么”而不是“怎样实现”采用一定的规格说明语言如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充34/150需求规格文档标准1引言1.1编写目的1.2项目背景（单位和与其他系统的关系）1.3定义（专门术语和缩写词）2任务概述2.1目标2.2运行环境2.3条件限制3数据描述3.1静态数据3.2动态数据3.3数据库描述3.4数据字典3.5数据采集4功能需求4.1功能划分4.2功能描述5性能需求5.1数据精确度5.2时间特性5.3适应性6运行需求5.1用户界面5.2硬件接口5.3软件接口5.4故障处理7其他需求（检测或验收标准、可用性、可维护性、可移植性、安全保密性）35/1505.2.7需求验证需求验证是软件需求阶段的一个重要环节，未经验证的需求给项目成功带来较大的需求风险需求验证对需求文档和制品进行质量评估，确保需求说明准确、完整包括以下内容：正确性一致性完整性可行性必要性可检验性需求的可