业务需求分析师

1业务需求分析师2目录目录.........................................................................................................................................2第1章.软件需求现状与常见问题.............................................................................41.1.软件需求现状分析...................................................................................41.2.需求常见问题分析...................................................................................5第2章.软件需求与需求工程......................................................................................82.1.软件需求...................................................................................................82.2.软件需求定义...........................................................................................82.2.1.需求的层次........................................................................................82.2.2.软件需求的类型..............................................................................102.2.3.软件需求的重要性..........................................................................122.2.4.优秀需求的标准..............................................................................132.3.软件需求工程.........................................................................................14第3章.需求开发.........................................................................................................163.1.需求开发管理.........................................................................................163.1.1.需求获取..........................................................................................163.1.2.需求分析..........................................................................................193.1.3.需求评审..........................................................................................49第4章.需求管理.........................................................................................................524.1.需求基线管理.........................................................................................524.2.需求变更管理.........................................................................................524.2.1.需求变更控制活动..........................................................................5434.2.2.需求变更控制委员会......................................................................564.2.3.需求变更波及分析..........................................................................594.2.4.需求稳定性评估..............................................................................624.3.需求跟踪.................................................................................................634.3.1.需求跟踪目的..................................................................................634.3.2.需求跟踪能力矩阵..........................................................................644.3.3.需求跟踪能力工具..........................................................................684.3.4.需求跟踪能力过程..........................................................................684.4.需求后评估.............................................................................................694.4.1.成本评估..........................................................................................704.4.2.效益评估..........................................................................................704第1章.软件需求现状与常见问题1.1.软件需求现状分析在信息化高速发展与行业竞争日趋激烈的今天，构建符合中国电信企业战略的信息化系统是我们IT专业人员要解决好地关键课题。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，许多项目无法达到预期目标，归根结底，软件需求质量是问题的主要根源之一。软件需求是软件项目关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点。它不像硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素。既然软件需求如此重要，那么需求相关的哪些因素是导致项目失败的根源？美国的第三方机构StandishGroup每隔几年都会对软件项目现状进行分析与统计，其分析报告“CHAOSREPORT”①的研究结果显示：高达31.1%的项目彻底失败，高达52.7%的项目进度超期或成本超支，被认为成功的项目仅有16.2%。为了帮助软件开发组织找到明确的改进方向，StandishGroup还总结出了十大成功保证和十大败因，如表1-1所示。在表1-1中可以看出，十大成功因素中有三个直接与需求相关（已加粗显示），累计权重达37.1%；而十大失败因素中有五个直接与需求相关，累计权重达51.6%，可见需求对项目影响程度之高。5表1-1项目成败因素分析成功因素权重失败因素权重用户参与15.9%不完整的需求13.1%决策层支持13.9%缺乏用户的参与12.4%清晰的需求描述13.0%资源不足10.6%合适的规划9.6%不且实际的用户期望9.9%现实的客户期望8.2%缺乏决策层的支持9.3%较小的里程碑7.7%需求变更频繁8.7%有才能的员工7.2%规划不足8.1%主权5.3%提供了不需要的功能7.5%清晰的远景和目标2.9%缺乏IT管理6.2%努力工作和稳定的员工2.4%技术能力缺乏4.3%其他13.9%其他9.9%1.2.需求常见问题分析下面简要地对需求相关的这些失败因素做初步的分析，更多的内容将随着本书的进程继续深入。1.不完整的需求在日常工作中，该问题经常困扰着我们——“什么样的需求是完整的呢？”如果没有一个有效的“需求完整性评价标准”，那么这个问题将是无解。要破解这个问题。首先应回答一个铺垫性的问题——“谁更有可能可以对需求的完整性进行评价？”。答案应该是“业务专家或业务代表要比it人员更适合对完整性进行评价”。要想让业务专家能够更好地参与到完整性评价中，应该做到以下两点：采用“业务导向”的树型层次结构展现需求文档。假若“需求规格说明书”中充斥着诸如数据字典、报表子系统、新增客户等以技术动词为主的字眼与结构，很有可能业务人员望而却步。而采用业务导向的结构，是用业务人员6熟悉的场景为索引，加之树型层析结构可以将宏观信息与微观信息进行有效剥离。按“组织层次”划分来完成需求的验证。日常工作中常见的场景是用业务代表的签字确认来代替需求验证。需求验证是重要的需求质量环节，目的是暴露出更多的错误，而确认则代表了职责。可一个企业中少有人能上通战略下解具体操作，为了让业务人员有效的验证需求，需求文档的树型结构应面对不同的层面：决策层、管理层、操作层，将需求分成不同部分，让合适的人验证适当的部分。2.缺乏用户参与在很多项目中，使用者都不能有效地参与到项目中来，诸如“你们先做，做出来我们试试，有问题再改”之类的话也是常常听到。主要应对措施是充分研究业务代表的关注点、利益点，通过业务利益争取使用者参与到需求活动中。3.不切实际的用户期望很多情况下，业务人员都会提出大量的需求，有些是技术上根本无法实现的，有的则是项目费用、项目时间等预算内无法实现的。究其原因，主要在于软件的无形和软件成本的不透明。要解决这样的问题，在当前国内的软件实施环境下，能做的是it人员主动地帮助使用者更好的理解软件成本，说明清楚为什么做不到，取得理解，达成一致才是关键。4.需求变更频繁导致需求变更的原因很多，常见的因素包括：开发人员对待需求开发的态度不认真7用户参与不够模棱两可的需求。用户和需求开发人员在理解上的差异。过于简单的规格说明。不准确的计划等。有效控制变更应该注意采取合理的需求管理方法：需求分析阶段尽可能采用原型或者用例方法明确用户需求