需求描述最佳实践

《需求描述最佳实践》由会员分享，可在线阅读，更多相关《需求描述最佳实践（26页珍藏版）》请在金锄头文库上搜索。

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

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

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

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

5、 客人预订 客人入住 客人退房 换房 提交服务记录 产品事件实例 查找空闲客房 记录客人信息 查找客人数据 记录预订数据 打印预订确认 记录入住数据 退房 记录服务,功能需求的形式 4,特性需求：文字形式，该产品应记录/显示/计算，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉 实例： 该产品应能将客户在某一期限内设为维修状态 该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。 该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房,功能需求的形式 5,屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层

6、需求 实例：,功能需求的形式 6,任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发 人员理解；便于说明 任务变体以及复杂的 任务 实例：,功能需求的形式 7,由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性 任务及支持：结 构化的文字说明， 描述任务、域问 题，提出可能的 方案。,功能需求的形式 8,场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。 实例：夜班 由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各

7、自的客房钥匙放在一起。 在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。,功能需求的形式 9,用例 数据流图 以“标准”作为需求 以“开发过程”作为需求,非功能需求的形式 1,开放尺度与开放目标：通常要求达到某个数字目标。 实例： 该产品应能检测超速，并在0.5秒内完成拍照 该产品应能够2分钟内计算并显示客户占用情况的预报表 Planguage表示法：,非功能

8、需求的形式 2,能力及准确度需求,非功能需求的形式 3,性能需求,需求规格说明书,规格描述的形式 文档：用结合合理的自然语言精心编写 图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系 形式化规格说明：逻辑语言(伪码、决策表、决策图) 常用模板 ISO/GB版：面向结构化分析方法的，较陈旧 RUP版：以面向对象分析方法，用例驱动 Volere版：很实用的一个第三方公司版本 Atlantic System Guild（）公司,1引言 1.1编写的目的 1.2背景 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资

9、料。 2任务概述 2.1目标 叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景 材料。解释被开发系统与其他有关系统之间的关系。 2.2用户的特点 列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长， 以及本系统的预期使用频度。 2.3假定和约束 列出进行本系统开发工作的假定和约束。 3需求规定 3.1对功能的规定 用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、 经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支 持的并行操作的用户数等指标。 3.2 对性能的规定 3.2.1精度 3.2

10、.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. 整体说明 让读者

11、对整个软件系统的需求有一个框架性的认识。主要包括产品总体 效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的 内容。 2.1用例模型 2.2 假设与依赖关系 3. 具体需求 3.1用例描述 3.2补充需求 易用性、可靠性、性能、其它 4.支持信息,需求文档编写原则,使用语法、标点正确的完整句子，使语句的段落简短明了 采用主动语态的表达方式：如“该系统将”，而非“将发生” 使用的术语应与术语表中定义的术语保持一致 将含糊不明确的顶层需求分解成足够详细的几个需求，消除歧义 需求声明应该具有一致的风格，例如“系统将”，“用户将” 当以“用户将”格式说明时，尽可能明确参与者 使用列表、数

12、字、图和表来表示信息 强调最重要的信息 避免使用语义不清的词语 以相同的详细程序编写 详细程度的把握：可以单独测试,歧义术语与改进,可接受、足够：具体定义可接受的内容和系统如何地此进行判断 差不多可行：不要让开发人员来确定什么是可行的 至少、最小、不多于、不超多：指定能够接受的最大值和最小值 在之间：定义终点是否在此范围内 依赖：描述依赖性的本质，是提供输入？是提前安装支持软件？ 有效的：定义系统如何有效地使用资源，系统执行特定的操作的速度如何，用户使用系统的容易程度如何 灵活的：描述一种方式 改进的、更好的、更快的、优越的：定量说明 包括、包括但不限于、等等、诸如：项目列表应包含所有可能性

13、最大化、最小化、最优：陈述对某些参数所接受的最大值和最小值,歧义术语与改进,一般情况下、理想情况下：描述系统在异常和非理想条件下的行为 可选择的：指明是系统选择、用户选择还是开发人员选择 合理、在必要的时候、在适当的地方：清晰解释如何判断 健壮的：定义系统如何处理异常和如何响应预料外的操作条件 无缝的、透明的、优雅的：将用户期望转化成能够观察的特性 若干：具体是多少，最小边界值和最大边界值 不应该：试着以肯定句来描述 最新技术水平：描述其具体含义 充 分的：指定具体包括哪些内容 支持、允许：精确定义系统将执行哪些功能 用户友好、简单、容易：描述系统特性，这些特性将达到客户的使用需要和对易用性的

14、期望,需求修正,原描述：后台任务管理器必须在固定的时间间隔内提供状态消息，并在每次时间间隔不得小于60秒。 什么是状态消息？什么条件下和以什么方式向用户提供这些消息？ 显示时间是多长？间隔时间不太明确，1毫秒行吗？ 修改后： 后台任务管理器应该在用户界面的指定区域显示状态信息 在后台任务进程启动后，消息必须每隔6010秒更新一次 消息应该保持持续的可见性 后台任务管理器在每次可以与后台任务进程进行通信时，都应该显示后台任务已完成的百分比 当完成后台任务时，后台任务管理器应该显示一个“已完成”的消息 如果后台任务中止执行，那后台任务管理器应该显示一个出错信息,需求修正,原描述：如果可能的话，应该根据主要法人帐号列表来在线确认所输入的帐号的有效性。 如何可能是指什么？是指技术上可行？运行时间可行？ 如果不能确定一定要，则应该用TBD来表示！ 修改后： 当请求者输入帐号时，系统将根据在线的主要法人帐号的列表来验证所输入的帐号。如果在此列表中找不到，则显示一个错误信息并拒绝订货。,需求修正,原描述：编辑器不应该提供可能带来灾难性后果的查询和替换选项 灾难性后果是什么？如果发现这个可能带来灾难性的查询/替换？ 重要的关注点实际上是：发生意外损坏或丢失时能够保护内容 修改后： 1.编辑器将要求用户确认全局性文本改动、删除和插入操作 2.应用程序应提供多级“撤消”功能,