需求描述最佳实践ppt课件

需求描述最佳实践1,定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。主要效益：需求前后一致，因而更加易懂引入成本：中应用成本：低使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。主要效率：需求更加易读易懂引入成本：相当低应用成本：低-中,需求描述最佳实践2,适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解还可以用于概括数字信息或描述事件和行为序列。主要效益：图解最适于记录需求关系引入成本：低应用成本：低实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画）,需求描述最佳实践3,用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。主要效益：更加简明、无二义性的需求描述引入成本：很低应用成本：低定量说明需求：只要有可能，就应该使用定量的数值说明系统的需求，非功能需求最有可能采用这一点。主要效益：无二义性地表达需求引入成本：低-中应用成本：低-中实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。,非功能需求可以使用度量,可靠性：出错时间、错误发生率有效性：请求后出错的可能性性能：每秒处理的事务数，对用户输入的响应时间存储利用：系统最大的尺寸(MB)可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值健壮性：系统出错后重新启动的时间完整性：系统出错时，允许的数据丢失的最大限度,数据需求的描述形式,数据模型：E-R模型框图：描述产品内、外的数据非常适合专家使用，但不便于用户使用数据词典：产品内、外数据的文字描述非常适合专家及用户数据表达式描述数据序列的简洁公式，适合于描述复合数据及消息协议非常适合于专家使用，也为许多用户所接受虚拟窗口简化的屏幕图像，有图像、真实数据，但无按钮、菜单非常适合专家及用户，非常适合于规划新的界面,功能需求的形式1,人、机职责划分：可采用DFD、UML表示域模型：人、机结合的模型物理模型：人、机各自的职责产品层需求：人、机职责划分,功能需求的形式2,上下文图：说明产品及其环境的图示为开发人员概括了所有接口大多数客户能不费力地理解上下文图,功能需求的形式3,事件列表与功能列表：产品要处理的事件，人、机合作处理的事件域事件实例：客人预订客人入住客人退房换房提交服务记录产品事件实例查找空闲客房记录客人信息查找客人数据记录预订数据打印预订确认记录入住数据退房记录服务,功能需求的形式4,特性需求：文字形式，该产品应记录/显示/计算，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉实例：该产品应能将客户在某一期限内设为维修状态该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房,功能需求的形式5,屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求实例：,功能需求的形式6,任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发人员理解；便于说明任务变体以及复杂的任务实例：,功能需求的形式7,由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性任务及支持：结构化的文字说明，描述任务、域问题，提出可能的方案。,功能需求的形式8,场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。实例：夜班由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。,功能需求的形式9,用例数据流图以“标准”作为需求以“开发过程”作为需求,非功能需求的形式1,开放尺度与开放目标：通常要求达到某个数字目标。实例：该产品应能检测超速，并在0.5秒内完成拍照该产品应能够2分钟内计算并显示客户占用情况的预报表Planguage表示法：,非功能需求的形式2,能力及准确度需求,非功能需求的形式3,性能需求,需求规格说明书,规格描述的形式文档：用结合合理的自然语言精心编写图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系形式化规格说明：逻辑语言(伪码、决策表、决策图)常用模板ISO/GB版：面向结构化分析方法的，较陈旧RUP版：以面向对象分析方法，用例驱动Volere版：很实用的一个第三方公司版本AtlanticSystemGuild（）公司,1引言1.1编写的目的1.2背景1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料列出用得着的参考资料。2任务概述2.1目标叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。2.2用户的特点列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。2.3假定和约束列出进行本系统开发工作的假定和约束。3需求规定3.1对功能的规定用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。3.2对性能的规定3.2.1精度3.2.2时间特性要求3.2.3灵活性3.3输入输出要求3.4数据管理能力要求（针对软件系统）3.5故障处理要求3.6其他专门要求4运行环境规定4.1设备列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：4.2支持软件列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。4.3接口说明该系统同其他系统之间的接口、数据通信协议等。4.4控制说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。,RUP版需求规约1.文档概述1.1目的1.2范围1.3定义、首字母缩写词和缩略语1.4参考资料1.5概述2.整体说明让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。2.1用例模型2.2假设与依赖关系3.具体需求3.1用例描述3.2补充需求易用性、可靠性、性能、其它4.支持信息,需求文档编写原则,使用语法、标点正确的完整句子，使语句的段落简短明了采用主动语态的表达方式：如“该系统将”，而非“将发生”使用的术语应与术语表中定义的术语保持一致将含糊不明确的顶层需求分解成足够详细的几个需求，消除歧义需求声明应该具有一致的风格，例如“系统将”，“用户将”当以“用户将”格式说明时，尽可能明确参与者使用列表、数字、图和表来表示信息强调最重要的信息避免使用语义不清的词语以相同的详细程序编写详细程度的把握：可以单独测试,歧义术语与改进,可接受、足够：具体定义可接受的内容和系统如何地此进行判断差不多可行：不要让开发人员来确定什么是可行的至少、最小、不多于、不超多：指定能够接受的最大值和最小值在之间：定义终点是否在此范围内依赖：描述依赖性的本质，是提供输入？是提前安装支持软件？有效的：定义系统如何有效地使用资源，系统执行特定的操作的速度如何，用户使用系统的容易程度如何灵活的：描述一种方式改进的、更好的、更快的、优越的：定量说明包括、包括但不限于、等等、诸如：项目列表应包含所有可能性最大化、最小化、最优：陈述对某些参数所接受的最大值和最小值,歧义术语与改进,一般情况下、理想情况下：描述系统在异常和非理想条件下的行为可选择的：指明是系统选择、用户选择还是开发人员选择合理、在必要的时候、在适当的地方：清晰解释如何判断健壮的：定义系统如何处理异常和如何响应预料外的操作条件无缝的、透明的、优雅的：将用户期望转化成能够观察的特性若干：具体是多少，最小边界值和最大边界值不应该：试着以肯定句来描述最新技术水平：描述其具体含义充分的：指定具体包括哪些内容支持、允许：精确定义系统将执行哪些功能用户友好、简单、容易：描述系统特性，这些特性将达到客户的使用需要和对易用性的期望,需求修正,原描述：后台任务管理器必须在固定的时间间隔内提供状态消息，并在每次时间间隔不得小于60秒。什么是状态消息？什么条件下和以什么方式向用户提供这些消息？显示时间是多长？间隔时间不太明确，1毫秒行吗？修改后：后台任务管理器应该在用户界面的指定区域显示状态信息在后台任务进程启动后，消息必须每隔6010秒更新一次消息应该保持持续的可见性后台任务管理器在每次可以与后台任务进程进行通信时，都应该显示后台任务已完成的百分比当完成后台任务时，后台任务管理器应该显示一个“已完成”的消息如果后台任务中止执行，那后台任务管理器应该显示一个出错信息,需求修正,原描述：如果可能的话，应该根据主要法人帐号列表来在线确认所输入的帐号的有效性。如何可能是指什么？是指技术上可行？运行时间可行？如果不能确定一定要，则应该用T