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

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

ID:55836299

大小:243.00 KB

页数:25页

时间:2020-06-09

《软件需求分析》第16章.需求验证.ppt_第1页
《软件需求分析》第16章.需求验证.ppt_第2页
《软件需求分析》第16章.需求验证.ppt_第3页
《软件需求分析》第16章.需求验证.ppt_第4页
《软件需求分析》第16章.需求验证.ppt_第5页
资源描述:

《《软件需求分析》第16章.需求验证.ppt》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、第16章.需求验证主要内容验证与确认需求验证需求验证方法问题修正需求验证的实践调查1.验证与确认——概念需求验证:以正确的方式建立需求需求集是正确的、完备的和一致的;技术上是可解决的;它们在现实世界中的满足是可行的和可验证的。需求确认:建立的需求是正确的每一条需求都是符合用户原意的系统验证:正确的建立系统系统能够在预期的环境中正确的执行设定的功能。系统确认:建立的系统是正确的建立的系统是符合系统需求和系统设计的1.验证与确认——软件工程的验证与确认主要内容验证与确认需求验证需求验证方法问题修正需求验证的实践调查2.需求

2、验证——概念验证普遍存在获得的用户需求是否正确和充分的支持业务需求?建立的分析模型是否正确的反映了问题域特性和需求?细化的系统需求是否充分和正确的支持用户需求?需求规格说明文档是否组织良好、书写正确?需求规格说明文档内的需求是否充分和正确的反映了涉众的意图?需求规格说明文档是否可以作为后续开发工作(设计、实现、测试等等)的基础?需求验证是专指在需求规格说明完成之后,对需求规格说明文档进行的验证活动2.需求验证——活动主要内容验证与确认需求验证需求验证方法评审原型与模拟开发测试用例用户手册编制利用跟踪关系自动化分析问题修

3、正需求验证的实践调查3.1评审由作者之外的其他人来检查产品问题的方法是主要的静态分析手段原则上,每一条需求都应该进行评审3.1评审——参与人员3.1评审——过程3.1评审——检查方法检查方法描述自由方法(Ad-hoc)没有为检查人员提供系统化的引导检查清单(Checklist-Based)以通用的检查清单来引导检查过程缺陷(Defect-Based)用于需求文档,根据缺陷的分类来组织和检查场景功能点(FunctionPoint-Based)按照功能点来组织和检查场景视角(Perspective-Based)按照不同涉众

4、类型的视角来组织和检查场景场景(Scenario-Based)对每一个场景,都利用一系列的问题或者细节要求,来引导检查过程。缺陷、功能点、视角都是场景方法的一个特例。逐步提升(StepwiseAbstraction)净室软件开发中的一种方法。阅读者描述一些独立代码段的功能,然后将描述的范围逐步扩大,描述的功能抽象逐步提高,直至阅读人员描述了整个评审物件3.1评审——类型3.2原型与模拟涉及到复杂的动态行为时成本较高3.3开发测试用例如果无法为某条需求定义完备的测试用例,那么它可能就存在着模糊、信息遗漏、不正确等缺陷例外

5、排斥性需求(ExclusiveRequirements)这种需求要求特定的行为绝对不会发生,例如需求可能会要求系统故障不能导致数据库的崩溃全局性非功能性需求(GlobalNon-FunctionalRequirements)例如可靠性、可用性等,对这些需求的测试往往都是大数据集的处理3.4用户手册编制验证功能需求对软件系统功能和实现的描述验证项目范围对系统没有实现的功能的描述验证异常流程需求问题和故障的解决验证环境与约束需求系统的安装和启动3.5利用跟踪关系业务需求用户需求系统需求如果业务需求和用户需求没有得到后项

6、需求(用户需求和系统需求)的充分支持,那么软件需求规格说明文档就存在不完备的缺陷。系统需求用户需求业务需求如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求,那么该需求就属于非必要的需求。3.6自动化分析主要内容验证与确认需求验证需求验证方法问题修正需求验证的实践调查4.问题修正需求澄清(RequirementsClarification)理解偏差:重新进行分析工作分析遗漏:重新分析和文档化这部分信息表达不当:重新以合适的方式表达缺失需求重新执行需求获取等一系列工作需求冲突协商解决不切实际的期望项目调

7、整与需求协商主要内容验证与确认需求验证需求验证方法问题修正需求验证的实践调查5.需求验证的实践调查需求验证是重要的需求验证是容易被忽视的需求验证的方法是多样的评审和原型最为广泛客户对线索(Threads)和场景(Scenarios)表现出了最大的兴趣技术人员、领域专家、客户以及用户是最合适的评审者实例分析需求虽然写好了也定稿了,但是并没有得到最终确认就开始了软件开发工作。这种现象主要是由于业务小组和技术小组沟通不全面造成的,在双方就某一问题产生分歧的情况下,没有一个能出来拍板的人决定(有权利决定的领导不参与开发和需求编

8、写)。所以整个项目的开发是在业务小组和技术小组的争论中走过的。经常出现业务小组提出的方案技术小组难以落实,等到后期变通修改造成功能损失的情况。因为需求得不到最终确认,一直在修改中,造成技术小组不停的修改已经编写完毕的模块,有些改动甚至涉及到公共基类的修改和各模块之间的关联,造成很大的浪费。实例分析系统开发过程中,没有好的办法检测需

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。