软件需求工程课件：第16章 需求验证

第16章.需求验证主要内容1.验证与确认2.需求验证3.需求验证方法4.问题修正5.需求验证的实践调查1.验证与确认概念n需求验证：以正确的方式建立需求q需求集是正确的、完备的和一致的；q技术上是可解决的；q它们在现实世界中的满足是可行的和可验证的。n需求确认：建立的需求是正确的q每一条需求都是符合用户原意的n系统验证：正确的建立系统q系统能够在预期的环境中正确的执行设定的功能。n系统确认：建立的系统是正确的q建立的系统是符合系统需求和系统设计的1.验证与确认软件工程的验证与确认主要内容1.验证与确认2.需求验证3.需求验证方法4.问题修正5.需求验证的实践调查2.需求验证概念n验证普遍存在q获得的用户需求是否正确和充分的支持业务需求？q建立的分析模型是否正确的反映了问题域特性和需求？细化的系统需求是否充分和正确的支持用户需求？q需求规格说明文档是否组织良好、书写正确？需求规格说明文档内的需求是否充分和正确的反映了涉众的意图？需求规格说明文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？n需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动2.需求验证活动主要内容1.验证与确认2.需求验证3.需求验证方法1.评审2.原型与模拟3.开发测试用例4.用户手册编制5.利用跟踪关系6.自动化分析4.问题修正5.需求验证的实践调查3.1 评审n由作者之外的其他人来检查产品问题的方法n是主要的静态分析手段n原则上，每一条需求都应该进行评审3.1 评审参与人员3.1 评审过程3.1 评审检查方法检查方法描述自由方法（Ad-hoc）没有为检查人员提供系统化的引导检查清单（Checklist-Based）以通用的检查清单来引导检查过程缺陷（Defect-Based）用于需求文档，根据缺陷的分类来组织和检查场景功能点（Function Point-Based）按照功能点来组织和检查场景视角（Perspective-Based）按照不同涉众类型的视角来组织和检查场景场景（Scenario-Based）对每一个场景，都利用一系列的问题或者细节要求，来引导检查过程。缺陷、功能点、视角都是场景方法的一个特例。逐步提升（Stepwise Abstraction）净室软件开发中的一种方法。阅读者描述一些独立代码段的功能，然后将描述的范围逐步扩大，描述的功能抽象逐步提高，直至阅读人员描述了整个评审物件3.1 评审类型3.2 原型与模拟n涉及到复杂的动态行为时n成本较高3.3 开发测试用例n如果无法为某条需求定义完备的测试用例，那么它可能就存在着模糊、信息遗漏、不正确等缺陷n例外q排斥性需求（Exclusive Requirements）n这种需求要求特定的行为绝对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃q全局性非功能性需求（Global Non-Functional Requirements）n例如可靠性、可用性等，对这些需求的测试往往都是大数据集的处理3.4 用户手册编制n验证功能需求q对软件系统功能和实现的描述n验证项目范围q对系统没有实现的功能的描述n验证异常流程需求q问题和故障的解决n验证环境与约束需求q系统的安装和启动3.5利用跟踪关系n业务需求用户需求系统需求q如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。n系统需求用户需求业务需求q如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。3.6自动化分析主要内容1.验证与确认2.需求验证3.需求验证方法4.问题修正5.需求验证的实践调查4.问题修正n需求澄清（Requirements Clarification）q理解偏差：重新进行分析工作q分析遗漏：重新分析和文档化这部分信息q表达不当：重新以合适的方式表达n缺失需求q重新执行需求获取等一系列工作n需求冲突q协商解决n不切实际的期望q项目调整与需求协商主要内容1.验证与确认2.需求验证3.需求验证方法4.问题修正5.需求验证的实践调查5.需求验证的实践调查n需求验证是重要的n需求验证是容易被忽视的n需求验证的方法是多样的q评审和原型最为广泛q客户对线索（Threads）和场景（Scenarios）表现出了最大的兴趣q技术人员、领域专家、客户以及用户是最合适的评审者实例分析(一个公司的业务管理系统)n问题q需求虽然写好了也定稿了，但是并没有得到最终确认就开始了软件开发工作。这种现象主要是由于业务小组和技术小组沟通不全面造成的，在双方就某一问题产生分歧的情况下，没有一个能出来拍板的人决定（有权利决定的领导不参与开发和需求编写）。q所以整个项目的开发是在业务小组和技术小组的争论中走过的。经常出现业务小组提出的方案技术小组难以落实，等到后期变通修改造成功能损失的情况。因为需求得不到最终确认，一直在修改中，造成技术小组不停的修改已经编写完毕的模块，有些改动甚至涉及到公共基类的修改和各模块之间的关联，造成很大的浪费。n解决q验证与确认+需求管理实例分析（地税系统）n问题q系统开发过程中，没有好的办法检测需求落实的情况。最后验收的时候功能是否实现由技术小组说了算。n解决q需求规格说明+需求验证与确认q用户为中心本章小结n验证与确认是软件工程当中一项重要的活动。需求验证是需求工程中发生的对需求规格说明文档进行的验证与确认活动n需求验证有多种有效的方法，实践中最为重要和广泛应用是的评审方法和原型方法n需求验证不仅要发现问题，而且要监督问题的解决思考题n用于需求获取的原型与用于需求验证的原型有何异同？n多种需求验证的方法应该如何结合运用？