《软件需求分析》第16章.需求验证

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