需求描述最佳实践.

需求描述最佳实践1定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。主要效益：需求前后一致，因而更加易懂引入成本：中应用成本：低使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。主要效率：需求更加易读易懂引入成本：相当低应用成本：低-中需求描述最佳实践2适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解还可以用于概括数字信息或描述事件和行为序列。主要效益：图解最适于记录需求关系引入成本：低应用成本：低实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画）需求描述最佳实践3用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。主要效益：更加简明、无二义性的需求描述引入成本：很低应用成本：低定量说明需求：只要有可能，就应该使用定量的数值说明系统的需求，非功能需求最有可能采用这一点。主要效益：无二义性地表达需求引入成本：低-中应用成本：低-中实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。非功能需求可以使用度量可靠性：出错时间、错误发生率有效性：请求后出错的可能性性能：每秒处理的事务数，对用户输入的响应时间存储利用：系统最大的尺寸(MB)可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值健壮性：系统出错后重新启动的时间完整性：系统出错时，允许的数据丢失的最大限度数据需求的描述形式数据模型：E-R模型框图：描述产品内、外的数据非常适合专家使用，但不便于用户使用数据词典：产品内、外数据的文字描述非常适合专家及用户数据表达式描述数据序列的简洁公式，适合于描述复合数据及消息协议非常适合于专家使用，也为许多用户所接受虚拟窗口简化的屏幕图像，有图像、真实数据，但无按钮、菜单非常适合专家及用户，非常适合于规划新的界面功能需求的形式1人、机职责划分：可采用DFD、UML表示域模型：人、机结合的模型物理模型：人、机各自的职责产品层需求：人、机职责划分查找空闲客房客人的要求客房域模型：合作的各方客人姓名查找空闲客房用户系统客人的要求空闲客房选定的客房号客房选定期限+客户类别物理模型：工作分工功能需求的形式2上下文图：说明产品及其环境的图示为开发人员概括了所有接口大多数客户能不费力地理解上下文图接待人酒店系统会计系统电话系统客人预订退房服务登记…确认发票功能需求的形式3事件列表与功能列表：产品要处理的事件，人、机合作处理的事件域事件实例：客人预订客人入住客人退房换房提交服务记录产品事件实例查找空闲客房记录客人信息查找客人数据记录预订数据打印预订确认记录入住数据退房记录服务功能需求的形式4特性需求：文字形式，该产品应记录/显示/计算…，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉实例：该产品应能将客户在某一期限内设为维修状态该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房功能需求的形式5屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求实例：功能需求的形式6任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发人员理解；便于说明任务变体以及复杂的任务实例：任务：1.2入住目的：为客人分配客房。将其标记为“占用”。开始计账。触发：/前提：客人抵达频率：平均0.5次入住/每房/每天关键情况：50人的旅游团子任务：1.查找客房2.将客人标记为“已入住”3.提供钥匙任务变体：1a.客户已预订1b.无合适客房2a.客人数据已在预订时记录2b.常客功能需求的形式7由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性任务及支持：结构化的文字说明，描述任务、域问题，提出可能的方案。任务：1.2入住目的：为客人分配客户……频率：……子任务：方案示例：1.查找客房问题：客人要求相邻的客房；商量价格系统在酒店图上显示空闲客房系统显示折扣价格（依时间、天气而定）2.记录客人，标记为“已入住”（标准的数据输入）3.提供钥匙问题：客人忘记归还钥匙客人需要两套钥匙系统打印电子钥匙每位客人一新钥匙任务变体1a.客人已经预订问题：客人标识不明确系统采用最接近匹配算法功能需求的形式8场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。实例：夜班由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。功能需求的形式9用例数据流图以“标准”作为需求以“开发过程”作为需求非功能需求的形式1开放尺度与开放目标：通常要求达到某个数字目标。实例：该产品应能检测超速，并在0.5秒内完成拍照该产品应能够2分钟内计算并显示客户占用情况的预报表Planguage表示法：预报速度[标识]：系统完成一份预报表有多快?[要点]尺度：由用户按启动按钮开始，到系统显示报表的平均秒数。测量表：在酒店接待的繁忙时段，用秒表测量10次必须：8分钟计划：承诺在4分钟内(供应商定义)希望：2分钟过去：作为批处理作为，需要1小时非功能需求的形式2能力及准确度需求能力需求：R1：即使存在更多的可用内容，产品也只应使用少于16MB的内存R2：同时的用户数2000R3：数据库容量：客人数10000（年增长20%)客房数1000R4：客户窗口应能显示至少200间房（已预订/占用），如一位“客人”为公司活动预订了多间房间准确度需求：R5：姓名字段的长度应为150字符R6：应允许提前两年预订R7：传感器的数据应具有14位的精度，并在两年之内可扩展到18位。R8：该产品应正确识别语音字母、数字，并应允许x%时间的工厂背景噪声。非功能需求的形式3性能需求性能需求：R1：在最大负荷时，产品应能处理100项支付交易/每秒à吞吐量R2：产品应能够在1秒内处理一项警告，5秒内处理1000项警告R3：在标准工作负荷时，产品的CPU使用率应少于50%R4：200页文档的前后翻页不应超过1秒，搜索一关键字不应超过5秒R5：切换到下一字段时，应能在0.2秒内做输入；切换至另一屏幕时，应能在1.3秒内做输入；系统应在20秒之内显示简单报表R6：显示报表时，95%的简单报表应少于30秒，其他报表应少于5分钟需求规格说明书规格描述的形式文档：用结合合理的自然语言精心编写图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系形式化规格说明：逻辑语言(伪码、决策表、决策图)常用模板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毫秒行吗？修改后：后台任务管理器应该在用户界面的指定区域显示状态信息在后台任务进程启动后，消息必须每