需求描述最佳实践.pptVIP

需求描述最佳实践 1 定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。 主要效益：需求前后一致，因而更加易懂 引入成本：中 应用成本：低 使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。 主要效率：需求更加易读易懂 引入成本：相当低 应用成本：低-中 需求描述最佳实践 2 适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解还可以用于概括数字信息或描述事件和行为序列。 主要效益：图解最适于记录需求关系 引入成本：低 应用成本：低 实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画） 需求描述最佳实践 3 用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。 主要效益：更加简明、无二义性的需求描述 引入成本：很低 应用成本：低 定量说明需求：只要有可能，就应该使用定量的数值说明系统的需求，非功能需求最有可能采用这一点。 主要效益：无二义性地表达需求 引入成本：低-中 应用成本：低-中 实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。 非功能需求可以使用度量 可靠性：出错时间、错误发生率 有效性：请求后出错的可能性 性能：每秒处理的事务数，对用户输入的响应时间 存储利用：系统最大的尺寸(MB) 可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值 健壮性：系统出错后重新启动的时间 完整性：系统出错时，允许的数据丢失的最大限度 数据需求的描述形式 数据模型：E-R模型 框图：描述产品内、外的数据 非常适合专家使用，但不便于用户使用 数据词典： 产品内、外数据的文字描述 非常适合专家及用户 数据表达式 描述数据序列的简洁公式，适合于描述复合数据及消息协议 非常适合于专家使用，也为许多用户所接受 虚拟窗口 简化的屏幕图像，有图像、真实数据，但无按钮、菜单 非常适合专家及用户，非常适合于规划新的界面 功能需求的形式 1 人、机职责划分：可采用DFD、UML表示 域模型：人、机结合的模型 物理模型：人、机各自的职责 产品层需求：人、机职责划分 功能需求的形式 2 上下文图：说明产品及其环境的图示 为开发人员概括了所有接口 大多数客户能不费力地理解上下文图 功能需求的形式 3 事件列表与功能列表：产品要处理的事件，人、机合作处理的事件 域事件实例： 客人预订 客人入住 客人退房 换房 提交服务记录 产品事件实例 查找空闲客房 记录客人信息 查找客人数据 记录预订数据 打印预订确认 记录入住数据 退房 记录服务 功能需求的形式 4 特性需求：文字形式，该产品应记录/显示/计算…，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉 实例： 该产品应能将客户在某一期限内设为维修状态 该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。 该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房 功能需求的形式 5 屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求 实例： 功能需求的形式 6 任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发人员理解；便于说明任务变体以及复杂的任务 实例： 功能需求的形式 7 由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性 任务及支持：结构化的文字说明，描述任务、域问题，提出可能的方案。 功能需求的形式 8 场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。 实例：夜班由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。在处理这项任务时，来了一个