软件需求讲义-第四部分.ppt

软件需求 四 需求文档与需求质量验证 软件需求规格说明需求验证需求评审 第16章 需求规格说明 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 需求规格说明概述 获取VS分析VS规格说明 需求获取目标是得到用户需求 收集需求信息需求分析目标是更深刻的理解用户需求 界定能够让用户满意的解决方案准则需求规格说明目标是定义用户需求 准确描述需求及其解决方案 你可以用三种方法编写软件需求规格说明 用好的结构化和自然语言编写文本型文档 建立图形化模型 这些模型可以描绘转换过程 系统状态和它们之间的变化 数据关系 逻辑流或对象类和它们的关系 编写形式化规格说明 这可以通过使用数学上精确的形式化逻辑语言来定义需求 软件需求太原理工大学软件学院2015 第16章软件需求规格说明 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 SRS SoftwareRequirementSpecification 是软件项目初期阶段重要的一步 它从问题域的识别和定义 逐步转移至解决域中 解决域需要用需求模型来描述 SRS提供了容纳这些模型的框架 一个完整的SRS不仅是包括长长的功能性需求列表 还包括外部接口描述和一些诸如质量属性 期望性能等非功能性需求 SRS是初期问题域的识别和描述 解决域需要用需求模型来描述 SRS需求规格说明书 软件需求太原理工大学软件学院2015 1 需求规格说明概述 需求规格说明活动 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 需求规格说明模版 IEEE ANSI830 1993 2 需求规格说明文档 作用 更好的传递软件系统的需求信息和解决方案给所有的开发者拓展人们的知识记忆能力作为合同协议的重要部分作为项目开发活动的一个重要依据发现和减少可能的需求错误 减少项目的返工 降低项目的工作量作为有效的智力资产 2 需求规格说明文档 忽视的原因 交流途径时间压力迭代式开发敏捷 2 需求规格说明文档 类型 2 需求规格说明文档 类型 2 需求规格说明文档 内容 前景和范围内问题域信息解决方案需求 2 需求规格说明文档 作者 项目管理者组织安排 提供条件需求工程师负责人 主导人文档写作人员有时会采用 节省需求工程师的时间涉众 用户 验证人 2 需求规格说明文档 读者 2 需求规格说明文档 手段 非形式化自然语言限制性文本半形式化结构化文本伪码 结构化英语模型语言图 表 形式化形式化语言数学语言 BNF Z 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 3 模版的选择与裁剪 动机 优秀的文档结构组织复用 模版选择与裁剪文字写作字词 句法写作技巧 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 4 文档写作技巧 原则 写作是一门艺术没有什么固定的规律有一些效用有限的经验原则文档的组织方式 常见情景的处理 常用的写作技巧 容易出错的地方等 文档化的目标是交流简洁 易读VS严格 准确不要机械的照搬某些标准和规则 有没有另外一种更容易理解的表达方式 是否一次性提供了太多的信息 对读者来说什么是重要的 什么是不重要的 是否太抽象了 需不需要举例说明 是否太专业了 需不需要解释原理 会不会引起读者对内容的错误解释 哪些内容有益于读者 有益于哪些读者 文档在整体上是不是过于机械 乏味或者松散 文档枯燥吗 令人厌烦吗 4 文档写作技巧 结构组织 所有内容位置得当借鉴和使用标准的文档模版引用或强化 但不重复引用而不是复制强化与重复引言与冗余元文本 4 文档写作技巧 表达方式 形式依赖于内容根据需要表达的内容 选择合适的表达方式使用系统的表达方式人们倾向于系统的表达方式使用相同的语句格式来描述所有的细节需求 使用列表或者表格来组织独立 并列的信息 使用编号来表达繁杂信息之间的关系 包括顺序关系 嵌套关系和层次关系 4 文档写作技巧 细节描述 定义术语表或数据字典术语不一致 方言 问题错误术语和冗余术语避免干扰文本 这一段的意思是 上一句话是指 避免歧义词汇表15 1 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 5 优秀需求规格说明文档的特性 完备性标准描述了用户的所有有意义的需求 包括功能 性能 约束 质量属性和对外接口 定义了软件对所有情况的所有实际输入 无论有效输入还是无效输入 的响应 为文档中的所有插图 图 表和术语 度量单位的定义提供了完整的引用和标记 前景和范围TBD问题 5 优秀需求规格说明文档的特性 一致性标准细节的需求不能同高层次的需求相冲突 例如系统需求不能和业务需求 用户需求互相矛盾同一层次的不同需求之间也不能互相冲突评审自动化检查 5 优秀需求规格说明文档的特性 根据重要性和稳定性分级建立需求的优先级可修改标准它的结构和风格使得人们可以对其中任一需求进行容易地 完整地 一致地修改 同时还不会影响文档现有的结构和风格文档的可修改性要求 有着条理分明并且易于使用的组织方式 包括目录 索引和显式的交叉引用 没有重复冗余 独立表达每个需求 而不是和其他需求混在一起 5 优秀需求规格说明文档的特性 可跟踪后向跟踪 Backwardtraceability 能找到需求的来源 例如和更早期文档的显式关联 前向跟踪 Forwardtraceability 能找到需求所对应的设计单元 实现源代码和测试用例等 它要求每个需求都要有唯一的标识或者可供引用的名称 主要内容 需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查 6 需求规格说明的实践调查 需求规格说明文档的编写和使用时间压力替代品迭代式开发 6 需求规格说明的实践调查 需求规格说明文档的内容 6 需求规格说明的实践调查 需求规格说明文档的内容 6 需求规格说明的实践调查 需求规格说明文档的内容 6 需求规格说明的实践调查 模版和示例的使用 6 需求规格说明的实践调查 需求规格说明文档的描述语言 实例分析 wiki的使用 由于时间压力以及采取迭代开发的方式 造成了该项目没有编写需求规格说明书 但是可以采用更为灵活的方式编写 例如wiki 我曾在某一预研性质的项目中使用wiki来完成各类文档 结果证明它非常好用 wiki非常适合用在迭代开发以及预研性质的项目中编写文档 实例分析 公司A 我们公司项目的需求规格说明书 主要存在以下几点问题模版不是很统一 具有很多个人的特点没有明确的业务需求 用户需求 系统需求 这三个层次 在需求规格说明书中或多或少地涵盖前三项内容 但显得不够饱满和清晰鉴于项目的状况 一般较少考虑硬件需求 倒是一般来说 项目上线选用的都是最新的硬件设备 成本较高 内容的书写 自然语言居多 出现歧义 省略 模糊的机会较多 质量不高从项目的后期来看 性能需求 约束 质量需求没有明确地分门别类地明确列出 导致后期项目中的各个业务流程还是基本可行 但是整体系统还是出现总体质量不满足的地方 实例分析 项目报告 需求分析报告中夹杂了很多专业名词和行业名词 例如横冲 平衡等等 有些部分客户看不懂 有些部分程序员看不懂 只有自己心里明白 但这样就会造成客户和程序员理解上的问题 另外报告中写得比较凌乱 没有把相关问题归类整合 编写目录 导致程序员零散地一条条对着开发 很多地方衔接不是很好 另外客户很多想法尤其一些重要部分在软件交付的时候会有所改变 需求文档的编写原则 句子和段落要短 要检查需求是否被有效地定义 需求编写者还要努力正确地把握细化程度 密切关注合成了多个需求的单个需求 通篇文档细节上要保持一致 高质量的SRS的一些特性 完整性一致性可修改性可追踪书上P169 评审需求规格说明书的常见问题 叙述的软件目标和系统的目标是否保持一致 所有系统元素的重要接口都已描述了吗 问题域的信息流和结构都已被恰当地定义了吗 图示是否清楚 每个图都可以不需要文字补充了吗 是否包括了所有主要的功能 它们都已描述清楚了吗 系统的功能和用户需求一致了吗 设计约束是现实可行的吗 是否考虑过开发的技术风险 是否考虑过其他可选的软件需求 检验标准是否被详细地陈述 它们能有效地检验系统是否成功吗 是否存在不一致性 是否信息被忽略或冗余 和客户全面接触过吗 客户的主要意见都已被考虑了吗 用户是否评审过初步的原型 计划的估算受到什么样的影响 发现需求规格说明书中问题的一些方法 搜寻说服性的连接词 例如 当然 因此 明确地 显然 并问 为什么 观察含糊的术语 例如 一些 有时 经常 通常 一般地 大多数 并进行澄清 当给出了不完整的列表时 确定已理解了所有的项 关键是查找 等等 如此这样 确定陈述的范围内条件清晰 例如 从10到100的校验代码范围究竟是整数 实数 还是复数 避免含糊的动词 如 处理 拒绝 处制 跳过 限制 等 它们可以有很多方式来解释 避免含糊的代词 例如 I O模块与数据校验模块通信 且设置它的控制标志 那么标志是谁的 查找蕴含了确定性判断的语句 例如 总是 每次 所有 无 永不 证明它们是合理的 某个术语一旦被明确地定义 就要在文中前后一致地使用 用图示的方法可以帮助理解 本章小结 需求规格说明定义解决方案和需求 承载需求分析的成果需求规格说明是一项复杂的活动 正确的文档写作要求准确的界定文档的特性掌握文档模版的裁剪技巧和文档的写作技巧 可以帮助提高需求规格说明文档写作的能力优秀的需求规格说明文档需要达到一定的要求 思考题 什么时候建立术语表 在需求获取和需求分析当中采用哪些手段可以保证最终需求集的完备性 一致性和正确性 第17章 需求验证与第18章需求评审 主要内容 验证与确认需求验证需求验证方法问题修正需求验证的实践调查 1 验证与确认 概念 需求验证 以正确的方式建立需求需求集是正确的 完备的和一致的 技术上是可解决的 它们在现实世界中的满足是可行的和可验证的 需求确认 建立的需求是正确的每一条需求都是符合用户原意的系统验证 正确的建立系统系统能够在预期的环境中正确的执行设定的功能 系统确认 建立的系统是正确的建立的系统是符合系统需求和系统设计的 第17章需求验证 需求验证所包括的活动是为了确定以下几方面的内容 软件需求规格说明正确描述了预期的系统行为和特征 从系统需求或其它来源中得到软件需求 需求是完整的和高质量的 所有对需求的看法是一致的 需求为继续进行产品设计 构造和测试提供了足够的基础 需求验证确保了需求符合良好特征并且符合需求规格说明的良好特性 需求验证的意义 需求验证并不仅仅是一个独立的阶段 一些验证活动 例如对迭代增量型软件需求规格说明的反复评审 将贯穿着反复获取需求 分析和编写规格说明的整个过程 当你的项目计划或实际工作中的独立任务破坏了结构性时 就要结合进行需求验证活动 为防止错误而花费1美元将可以为你修补错误节省3 10美元 Jones1994 1 验证与确认 软件工程的验证与确认 主要内容 验证与确认需求验证需求验证方法问题修正需求验证的实践调查 2 需求验证 概念 验证普遍存在获得的用户需求是否正确和充分的支持业务需求 建立的分析模型是否正确的反映了问题域特性和需求 细化的系统需求是否充分和正确的支持用户需求 需求规格说明文档是否组织良好 书写正确 需求规格说明文档内的需求是否充分和正确的反映了涉众的意图 需求规格说明文档是否可以作为后续开发工作 设计 实现 测试等等 的基础 需求验证是专指在需求规格说明完成之后 对需求规格说明文档进行的验证活动 2 需求验证 活动 测试与开发平行 验收测试以用户需求为基础 系统测试以功能需求为基础 集成测试以系统体系结构为基础 软件开发的V字模型 软件需求太原理工大学软件学院2015 主要内容 验证与确认需求验证需求验证方法评审原型与模拟开发测试用例用户手册编制利用跟踪关系自动化分析问题修正需求验证的实践调查 3 1评审 由作者之外的其他人来检查产品问题的方法是主要的静态分析手段原则上 每一条需求都应该进行评审 3 1评审 参与人员 3 1评审 过程 3 1评审 检查方法 3 1评审 类型 3 2原型与模拟 涉及到复杂的动态行为时成本较高 3 3开发测试用例 如果无法为某条需求定义完备的测试用例 那么它可能就存在着模糊 信息遗漏 不正确等缺陷例外排斥性需求 ExclusiveRequirements 这种需求要求特定的行为绝对不会发生 例如需求可能会要求系统故障不能导致数据库的崩溃全局性非功能性需求 GlobalNon FunctionalRequirements 例如可靠性 可用性等 对这些需求的测试往往都是大数据集的处理 3 4用户手册编制 验证功能需求对软件系统功能和实现的描述验证项目范围对系统没有实现的功能的描述验证异常流程需求问题和故障的解决验证环境与约束需求系统的安装和启动 3 5利用跟踪关系 业务需求 用户需求 系统需求如果业务需求和用户需求没有得到后项需求 用户需求和系统需求 的充分支持 那么软件需求规格说明文档就存在不完备的缺陷 系统需求 用户需求 业务需求如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求 那么该需求就属于非必要的需求 3 6自动化分析 主要内容 验证与确认需求验证需求验证方法问题修正需求验证的实践调查 4 问题修正 需求澄清 RequirementsClarification 理解偏差 重新进行分析工作分析遗漏 重新分析和文档化这部分信息表达不当 重新以合适的方式表达缺失需求重新执行需求获取等一系列工作需求冲突协商解决不切实际的期望项目调整与需求协商 主要内容 验证与确认需求验证需求验证方法问题修正需求验证的实践调查 5 需求验证的实践调查 需求验证是重要的需求验证是容易被忽视的需求验证的方法是多样的评审和原型最为广泛客户对线索 Threads 和场景 Scenarios 表现出了最大的兴趣技术人员 领域专家 客户以及用户是最合适的评审者 实例分析 一个公司的业务管理系统 问题需求虽然写好了也定稿了 但是并没有得到最终确认就开始了软件开发工作 这种现象主要是由于业务小组和技术小组沟通不全面造成的 在双方就某一问题产生分歧的情况下 没有一个能出来拍板的人决定 有权利决定的领导不参与开发和需求编写 所以整个项目的开发是在业务小组和技术小组的争论中走过的 经常出现业务小组提出的方案技术小组难以落实 等到后期变通修改造成功能损失的情况 因为需求得不到最终确认 一直在修改中 造成技术小组不停的修改已经编写完毕的模块 有些改动甚至涉及到公共基类的修改和各模块之间的关联 造成很大的浪费 解决验证与确认 需求管理 实例分析 地税系统 问题系统开发过程中 没有好的办法检测需求落实的情况 最后验收的时候功能是否实现由技术小组说了算 解决需求规格说明 需求验证与确认用户为中心 本章小结 验证与确认是软件工程当中一项重要的活动 需求验证是需求工程中发生的对需求规格说明文档进行的验证与确认活动需求验证有多种有效的方法 实践中最为重要和广泛应用是的评审方法和原型方法需求验证不仅要发现问题 而且要监督问题的解决 思考题 用于需求获取的原型与用于需求验证的原型有何异同 多种需求验证的方法应该如何结合运用 第18章需求评审 需求评审为涉众们提供了在特定问题上达成共识的方法 评审类型 评审 检察 走查 进行成功的评审有几个关键要素 理解评审流程 确保评审员理解自己的角色 指定协调员 使评审保持简短 严格按照议程进行 确定问题 而不要解决问题 评审过程 需求评审中常见的问题 软件需求规格说明书的评审清单 非正式评审 非正式评审的方法可以是把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍 walkthrough 或是由产品开发者描述产品 征求大家的意见 非正式评审对于获得分散而随机的反馈是有效的 但非正式评审是非系统化的 不彻底的 它在实施过程中具有不一致性 正式评审 正式评审则遵循预先定义好的一系列步骤过程 正式评审内容需要记录在案 它包括确定材料 评审员 评审小组对产品是否完整或是否需要进一步工作的判定 以及对所发现的错误和所提出的问题的总结 正式评审小组的成员对评审的质量负责 而开发者则最终对他们所开发的产品的质量负责 评审类型 IEEE 评审 一次正式的会议 在会议上向用户 客户或其他相关各方介绍一个或一组工件 以征求对方的意见和批准 检查 一种正式的评估方法 将由非制作者本人的个人或小组详细检查工件 以查明是否有错误 是否违反开发标准 是否存在其他问题 走查 一个评审过程 由某个开发人员领导一个或多个开发团队成员对他 或她 所编写的一段工件进行检查 同时 由其他成员针对技术 风格 可能的错误 是否违反开发标准和其他问题提出问题并发表意见 评审流程 评审流程是一个重复进行的循环过程