需求规格说明介绍.ppt

* * 第15章. 需求规格说明主要内容 第1节 需求规格说明概述 第2节 需求规格说明文档 第3节 模版的选择与裁剪 第4节 文档写作技巧 第5节 优秀需求规格说明文档的特性 第6节 需求规格说明的实践调查 第1节 需求规格说明概述 需求获取 目标是得到用户需求——收集需求信息 需求分析 目标是更深刻的理解用户需求——界定能够让用户满意的解决方案准则 需求规格说明 目标是定义用户需求——准确描述需求及其解决方案 （1）获取——分析——规格说明 （2）需求规格说明活动 第2节 需求规格说明文档（1）作用 更好的传递软件系统的需求信息和解决方案给所有的开发者 拓展人们的知识记忆能力 作为合同协议的重要部分 作为项目开发活动的一个重要依据 发现和减少可能的需求错误，减少项目的返工，降低项目的工作量 作为有效的智力资产 （2）忽视的原因 交流途径 时间压力 迭代式开发 敏捷 （3）类型 （4）内容 前景和范围内容 问题域信息 解决方案 需求 （5）作者 项目管理者 组织安排、提供条件 需求工程师 负责人、主导人 文档写作人员 有时会采用，节省需求工程师的时间 涉众（用户） 验证人 （6）读者 （7）手段 非形式化 自然语言 限制性文本 半形式化 结构化文本 伪码/结构化英语 模型语言 图、表… 形式化 形式化语言 数学语言：BNF，Z… 第3节 模版的选择与裁剪 优秀的文档 结构组织 复用：模版 选择与裁剪 文字写作 字词、句法 写作技巧 （1）动机 （2）模板 第4节 文档写作技巧（1）原则 写作是一门艺术 没有什么固定的规律 有一些效用有限的经验原则 文档的组织方式； 常见情景的处理； 常用的写作技巧； 容易出错的地方等。 文档化的目标是交流 简洁、易读 VS 严格、准确 不要机械的照搬某些标准和规则 有没有另外一种更容易理解的表达方式？ 是否一次性提供了太多信息？ 对读者来说什么是重要的，什么是不重要的？ 是否太抽象了？需不需要举例说明？ 是否太专业了？需不需要解释原理？ 会不会引起读者对内容的错误解释？ 哪些内容有益于读者？有益于哪些读者？ 文档在整体上是不是过于机械、乏味或者松散？ 文档枯燥吗？令人厌烦吗？ （2）结构组织 所有内容位置得当 借鉴和使用标准的文档模版 引用或强化，但不重复 引用而不是复制 强化与重复 引言与冗余元文本 （3）表达方式 形式依赖于内容 根据需要表达的内容，选择合适的表达方式 使用系统的表达方式 人们倾向于系统的表达方式 使用相同的语句格式来描述所有的细节需求。 使用列表或者表格来组织独立、并列的信息。 使用编号来表达繁杂信息之间的关系，包括顺序关系、嵌套关系和层次关系。 （4）细节描述 定义术语表或数据字典 术语不一致 “方言”问题 错误术语和冗余术语 避免干扰文本 “这一段的意思是…” “上一句话是指…” 避免歧义词汇 表15－1 歧义词汇 改进方法 可接受的、足够的 具体定义可接受的内容，说明系统怎样判断“可接受”或“足够” 大概可行的、差不多可行的 不要让开发人员来判断“大概”和“差不多”到底是否成立。应将其标记为待确定问题并标明解决日期 至少、最小、不多于、不超过 明确指定能够接受的最大值和最小值 在……之间 明确说明两个端点是否在范围之内 依赖 描述依赖的原因，数据依赖？服务依赖？还是资源依赖？等等 有效的 明确“有效”所意味的具体实际情况 快的、迅速的 明确指定系统在时间或速度上可接受的最小值 灵活的 描述系统为了响应条件变化或需求变化而可能发生的变更方式 改进的、更好的、更快的、优越的 定量说明在一个专门的功能领域内，充分改进的程度和效果 包括、包括但不限于、等等、诸如 应该列举所有的可能性，否则就无法进行设计和测试 最大化、最小化、最优 说明对某些参数所能接受的最大值和最小值 一般情况下、理想情况下 需要增加描述系统在异常和非理想情况下的行为 可选择地 具体说明是系统选择、用户选择还是开发人员选择 合理的、在必要的时候、在适当的地方 明确怎样判断合理、必要和适当 健壮的 显式定义系统如何处理异常和如何响应预料之外的操作 无缝的、透明的、优雅的 将词汇里面所反映的用户期望转化成能够观察到的产品特性 若干 声明具体是多少，或提供某一范围内的最小边界值和最大边界值 不应该 试着以肯定的方式陈述需求，描述系统应该做什么 最新技术水平的 定义其具体含义，即“最新技术水平”意味什么 充分的 说明“充分”具体包括哪些内容 支持、允许 精确地定义系统的功能，这些功能组合起来支持某些能力 用户友好的、简单的、容易的 描述系统特性，用这些特性说明词汇所代表的用户期望的实质 第5节 优秀需求规格说明文档的特性 完备性 标准 描述了用户的所有有