需求描述最佳实践

1、需求描述最佳实践需求描述最佳实践 1l定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。 主要效益：需求前后一致，因而更加易懂 引入成本：中 应用成本：低l使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。 主要效率：需求更加易读易懂 引入成本：相当低 应用成本：低-中需求描述最佳实践需求描述最佳实践 2l适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解

2、还可以用于概括数字信息或描述事件和行为序列。 主要效益：图解最适于记录需求关系 引入成本：低 应用成本：低 实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画）需求描述最佳实践需求描述最佳实践 3l用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。 主要效益：更加简明、无二义性的需求描述 引入成本：很低 应用成本：低l定量说明需求：只要有可能，就

3、应该使用定量的数值说明系统的需求，非功能需求最有可能采用这一点。 主要效益：无二义性地表达需求 引入成本：低-中 应用成本：低-中 实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。非功能需求可以使用度量非功能需求可以使用度量l可靠性：出错时间、错误发生率l有效性：请求后出错的可能性l性能：每秒处理的事务数，对用户输入的响应时间l存储利用：系统最大的尺寸(MB)l可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值l健壮性：系统出错后重新启动的时间l完整性：系统出错时，允许的数据丢失的最大限度 数据需求的描述形式数据需求的描述形式l数据模型：E-R模型

4、框图：描述产品内、外的数据 非常适合专家使用，但不便于用户使用l数据词典： 产品内、外数据的文字描述 非常适合专家及用户l数据表达式 描述数据序列的简洁公式，适合于描述复合数据及消息协议 非常适合于专家使用，也为许多用户所接受l虚拟窗口 简化的屏幕图像，有图像、真实数据，但无按钮、菜单 非常适合专家及用户，非常适合于规划新的界面功能需求的形式功能需求的形式 1l人、机职责划分：可采用DFD、UML表示 域模型：人、机结合的模型 物理模型：人、机各自的职责 产品层需求：人、机职责划分功能需求的形式功能需求的形式 2l上下文图：说明产品及其环境的图示 为开发人员概括了所有接口 大多数客户能不费力地

5、理解上下文图功能需求的形式功能需求的形式 3l事件列表与功能列表：产品要处理的事件，人、机合作处理的事件l域事件实例： 客人预订 客人入住 客人退房 换房 提交服务记录l产品事件实例 查找空闲客房 记录客人信息 查找客人数据 记录预订数据 打印预订确认 记录入住数据 退房 记录服务功能需求的形式功能需求的形式 4l特性需求：文字形式，该产品应记录/显示/计算，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉l实例： 该产品应能将客户在某一期限内设为维修状态 该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。 该产品也应支持根据客户类型，而不是客房号的

6、预订。客人入住时才分配实例客房功能需求的形式功能需求的形式 5l屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求l实例：功能需求的形式功能需求的形式 6l任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发人员理解；便于说明任务变体以及复杂的任务l实例：功能需求的形式功能需求的形式 7l由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性l任务及支持：结构化的文字说明，描述任务、域问题，提出可能的方案。功能需求的形式功能需求的形式 8l场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。l实

7、例：夜班由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。功能需求的形式功能需求的形式 9l用例l数据流图l以“标准”作为需求l以“开发过程”作为需求非功能需求的形式非功能需求的形式 1l

8、开放尺度与开放目标：通常要求达到某个数字目标。l实例： 该产品应能检测超速，并在0.5秒内完成拍照 该产品应能够2分钟内计算并显示客户占用情况的预报表lPlanguage表示法：非功能需求的形式非功能需求的形式 2l能力及准确度需求非功能需求的形式非功能需求的形式 3l性能需求需求规格说明书需求规格说明书l规格描述的形式 文档：用结合合理的自然语言精心编写 图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系 形式化规格说明：逻辑语言(伪码、决策表、决策图)l常用模板 ISO/GB版：面向结构化分析方法的，较陈旧 RUP版：以面向对象分析方法，用例驱动 Volere版

9、：很实用的一个第三方公司版本Atlantic System Guild（）公司 1引言 1.1编写的目的 1.2背景 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料。2任务概述 2.1目标 叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景 材料。解释被开发系统与其他有关系统之间的关系。 2.2用户的特点 列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长， 以及本系统的预期使用频度。 2.3假定和约束 列出进行本系统开发工作的假定和约束。3需求规定 3.1对功能的规定 用列表

10、的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、 经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支 持的并行操作的用户数等指标。 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

11、控制 说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。 RUP版需求规约1. 文档概述 1.1目的 1.2范围 1.3 定义、首字母缩写词和缩略语 1.4参考资料 1.5 概述2. 整体说明 让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。 2.1用例模型 2.2 假设与依赖关系3. 具体需求 3.1用例描述 3.2补充需求 易用性、可靠性、性能、其它4.支持信息需求文档编写原则需求文档编写原则l使用语法、标点正确的完整句子，使语句的段落简短明了l采用主动语态的表达方式：如“该系统将”，而非“将

12、发生”l使用的术语应与术语表中定义的术语保持一致l将含糊不明确的顶层需求分解成足够详细的几个需求，消除歧义l需求声明应该具有一致的风格，例如“系统将”，“用户将”l当以“用户将”格式说明时，尽可能明确参与者l使用列表、数字、图和表来表示信息l强调最重要的信息l避免使用语义不清的词语l以相同的详细程序编写l详细程度的把握：可以单独测试歧义术语与改进歧义术语与改进l可接受、足够：具体定义可接受的内容和系统如何地此进行判断l差不多可行：不要让开发人员来确定什么是可行的l至少、最小、不多于、不超多：指定能够接受的最大值和最小值l在之间：定义终点是否在此范围内l依赖：描述依赖性的本质，是提供输入？是提前

13、安装支持软件？l有效的：定义系统如何有效地使用资源，系统执行特定的操作的速度如何，用户使用系统的容易程度如何l灵活的：描述一种方式l改进的、更好的、更快的、优越的：定量说明l包括、包括但不限于、等等、诸如：项目列表应包含所有可能性l最大化、最小化、最优：陈述对某些参数所接受的最大值和最小值歧义术语与改进歧义术语与改进l一般情况下、理想情况下：描述系统在异常和非理想条件下的行为l可选择的：指明是系统选择、用户选择还是开发人员选择l合理、在必要的时候、在适当的地方：清晰解释如何判断l健壮的：定义系统如何处理异常和如何响应预料外的操作条件l无缝的、透明的、优雅的：将用户期望转化成能够观察的特性l若干

14、：具体是多少，最小边界值和最大边界值 l不应该：试着以肯定句来描述l最新技术水平：描述其具体含义l充 分的：指定具体包括哪些内容l支持、允许：精确定义系统将执行哪些功能l用户友好、简单、容易：描述系统特性，这些特性将达到客户的使用需要和对易用性的期望需求修正需求修正l原描述：后台任务管理器必须在固定的时间间隔内提供状态消息，并在每次时间间隔不得小于60秒。l什么是状态消息？什么条件下和以什么方式向用户提供这些消息？l显示时间是多长？间隔时间不太明确，1毫秒行吗？l修改后：后台任务管理器应该在用户界面的指定区域显示状态信息在后台任务进程启动后，消息必须每隔6010秒更新一次消息应该保持持续的可见性后台任务管理器在每次可以与后台任务进程进行通信时，都应该显示后台任务已完成的百分比当完成后台任务时，后台任务管理器应该显示一个“已完成”的消息如果后台任务中止执行，那后台任务管理器应该显示一个出错信息需求修正需求修正l原描述：如果可能的话，应该根据主要法人帐号列表来在线确认所输入的帐号的有效性。l如何可能是指什么？是指技术上可行？运行时间可行？l如果不能确定一定要，则应该用TBD来表示！l修改后：当请求者输入帐号时，系统将根据在线的主要法人帐号的列表来验证所输入的帐号。如果在此列表中找不到，则显示一个错误信息并拒绝订货。需求修正需求修正l原描述：原描述：编辑器不应该提供可能带来灾难性后果的