《(2020年）(业务管理）业务需求分析师》由会员分享，可在线阅读，更多相关《(2020年）(业务管理）业务需求分析师（71页珍藏版）》请在金锄头文库上搜索。
1、业务需求分析师目 录目 录2第1章.软件需求现状与常见问题71.1.软件需求现状分析71.2.需求常见问题分析8第2章.软件需求与需求工程112.1.软件需求112.2.软件需求定义112.2.1.需求的层次112.2.2.软件需求的类型132.2.3.软件需求的重要性152.2.4.优秀需求的标准162.3.软件需求工程17第3章.需求开发193.1.需求开发管理193.1.1.需求获取193.1.2.需求分析223.1.3.需求评审52第4章.需求管理554.1.需求基线管理554.2.需求变更管理554.2.1.需求变更控制活动574.2.2.需求变更控制委员会594.2.3.需求变更波
2、及分析624.2.4.需求稳定性评估654.3.需求跟踪664.3.1.需求跟踪目的664.3.2.需求跟踪能力矩阵674.3.3.需求跟踪能力工具714.3.4.需求跟踪能力过程714.4.需求后评估724.4.1.成本评估734.4.2.效益评估73第1章. 软件需求现状与常见问题1.1. 软件需求现状分析在信息化高速发展与行业竞争日趋激烈的今天，构建符合中国电信企业战略的信息化系统是我们IT专业人员要解决好地关键课题。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，许多项目无法达到预期目标，归根结底，软件需求质量是问题的主要根源之一。软件需求是软件项目关键的一个输
3、入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点。它不像硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素。既然软件需求如此重要，那么需求相关的哪些因素是导致项目失败的根源？美国的第三方机构Standish Group 每隔几年都会对软件项目现状进行分析与统计，其分析报告“CHAOS REPORT”的研究结果显示：高达31.1%的项目彻底失败，高达52.7%的项目进度超期或成本超支，被认为成功的项目仅有16.2%。为了帮助软件开发组织找到明确的改进方向，Standish Group还总结出了十大成功
4、保证和十大败因，如表1-1所示。在表1-1中可以看出，十大成功因素中有三个直接与需求相关（已加粗显示），累计权重达37.1%；而十大失败因素中有五个直接与需求相关，累计权重达51.6%，可见需求对项目影响程度之高。表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%清晰的
5、远景和目标2.9%缺乏IT管理6.2%努力工作和稳定的员工2.4%技术能力缺乏4.3%其他13.9%其他9.9%1.2. 需求常见问题分析下面简要地对需求相关的这些失败因素做初步的分析，更多的内容将随着本书的进程继续深入。1. 不完整的需求在日常工作中，该问题经常困扰着我们“什么样的需求是完整的呢？”如果没有一个有效的“需求完整性评价标准”，那么这个问题将是无解。要破解这个问题。首先应回答一个铺垫性的问题“谁更有可能可以对需求的完整性进行评价？”。答案应该是“业务专家或业务代表要比it人员更适合对完整性进行评价”。要想让业务专家能够更好地参与到完整性评价中，应该做到以下两点： 采用“业务导向”
6、的树型层次结构展现需求文档。假若“需求规格说明书”中充斥着诸如数据字典、报表子系统、新增客户等以技术动词为主的字眼与结构，很有可能业务人员望而却步。而采用业务导向的结构，是用业务人员熟悉的场景为索引，加之树型层析结构可以将宏观信息与微观信息进行有效剥离。 按“组织层次”划分来完成需求的验证。日常工作中常见的场景是用业务代表的签字确认来代替需求验证。 需求验证是重要的需求质量环节，目的是暴露出更多的错误，而确认则代表了职责。可一个企业中少有人能上通战略下解具体操作，为了让业务人员有效的验证需求，需求文档的树型结构应面对不同的层面：决策层、管理层、操作层，将需求分成不同部分，让合适的人验证适当的部
7、分。2. 缺乏用户参与在很多项目中，使用者都不能有效地参与到项目中来，诸如“你们先做，做出来我们试试，有问题再改”之类的话也是常常听到。主要应对措施是充分研究业务代表的关注点、利益点，通过业务利益争取使用者参与到需求活动中。3. 不切实际的用户期望很多情况下，业务人员都会提出大量的需求，有些是技术上根本无法实现的，有的则是项目费用、项目时间等预算内无法实现的。究其原因，主要在于软件的无形和软件成本的不透明。要解决这样的问题，在当前国内的软件实施环境下，能做的是it人员主动地帮助使用者更好的理解软件成本，说明清楚为什么做不到，取得理解，达成一致才是关键。4. 需求变更频繁导致需求变更的原因很多，
8、常见的因素包括：l 开发人员对待需求开发的态度不认真l 用户参与不够l 模棱两可的需求。l 用户和需求开发人员在理解上的差异。l 过于简单的规格说明。l 不准确的计划等。有效控制变更应该注意采取合理的需求管理方法：l 需求分析阶段尽可能采用原型或者用例方法明确用户需求。l 采用严格的需求变更管理流程。l 采用良好的体系结构。l 采用面向对象思想。详细的方法请参见第3章节内容。5. 提供了不需要的功能很多项目中都或多或少的含了些很少使用或无人使用的功能，这种情况如何在事前预防呢？在需求阶段有效地划分优先级是个办法。这里所说的优先级划分不是“拍脑袋”的产物，而是真正基于业务领域知识来衡量需求的必要
9、性和充分性，在此基础上做出划分。第2章节有关于“合理划分优先级的方法”的详细说明。上述分析是需求工作中常见问题的解决建议，分析比较粗浅。若要有效的解决问题，就需要反思问题背后的本质原因，掌握需求理论与工作方法，针对性的找到适用的需求方法，构思、尝试出真正在本组织内有效的缓解手段。第2章. 软件需求与需求工程1.2.1.2.2.1. 软件需求2.2. 软件需求定义什么是软件需求，这个看似简单的问题并不好回答。也许有很多人简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解并不完整，本章将对一些与需求相关的关键概念进行阐述。软件需求是指用户对软件的功能和性能的要求，就是用
10、户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。软件人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的需求规格说明的过程。对于软件项目的需求，首先要明确用户的要求，澄清模糊的需求，与用户达成共识。2.2.1. 需求的层次有时也可以将软件需求按照层次来说明，包括业务需求、用户需求、软件需求、软件需求规格等层次，它们的关系如下图1-1所示。图表 21软件需求按照层次1. 业务需求业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定。因为业务需求的提出人通常是企业的管理人员，它完全是从业
11、务角度描述的，是指导软件开发的高层需求。实际上在项目立项阶段就整理完成了。2. 用户需求用户需求是指软件使用者的要求和软件应满足的用户特性，一般是用户协助提供。通常是在业务需求定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。用户需求是需求调研的产物，它具有以下特点： 零散：用户会提出不同角度、不同层面、不同粒度的需求，而且通常是以一句话的形式提出的。 存在矛盾：由于用户处于企业组织的不同层面、地域等，难免出现盲人摸象的现象，从而导致需求的片面性，甚至在不同用户之间会有不同的观点。正因为如此，我们还需要对用户需求（也叫原始需求）进行分析整理，从而整理出更加精确的
12、需求说明。3. 软件需求软件需求定义了开发人员必须实现的软件功能，使得用户通过使用此软件能完成它们的任务，从而满足业务需求。它是分析人员在对用户需求进行分析、提炼、整理，从而生成指导开发的、更精确的软件需求。它是需求分析与建模的产物，即形成软件需求规格。软件需求规格充分描述了软件系统应具有的外部行为，它描述了系统展现给用户的行为和执行的操作等。它包括：产品必须遵从的标准、规范和合约；外部界面的具体细节；非功能性需求（例如性能要求等）；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特性进行描述，从而反映产品功能。多角度描述产品对
13、用户和开发人员都极为重要。软件需求规格在开发、测试、质量保证、项目管理以及相关项目功能中都起到了重要的作用。2.2.2. 软件需求的类型软件需求可以分为功能需求、非功能需求和设计约束三种类型。1. 功能需求对于功能需求而言，最为关键的地方是如何对其进行组织，否则一句话、一句话的描述就会显得十分零散，很难保证开发人员逐一满足这些需求。在传统的方法论中，会以系统-子系统-模块-子模块的层次结构来组织，但它更多的是按照程序的结构来梳理，会割裂用户的使用场景。为了解决这个问题，现代需求理论更加强调需求分析人员从用户的角度，将系统理解为一个黑盒子，从横向的使用视角来整理需求。不管是RUP的用例方法还是X
14、P的用户故事，以及特征驱动开发的Feature,都是从这个角度进行梳理的。本教材推荐使用用例的方法。2. 非功能性需求非功能需求是一些限制性要求，是对实际使用环境所做的要求，例如性能要求、可靠性要求、安全性要求等。非功能需求比功能需求要求更严格，更不易满足，因为如果不能满足非功能需求，系统将无法运行。非功能需求方面常见的问题有两个：一是信息传递的无效性；二是忽略了非功能需求的局部性。 信息传递的无效性：很多需求规格说明书中，会通过一个小章节来说明非功能需求，列出诸如高可靠性、高可用性、高扩展性等要求。但很多开发人员根本不看它，因为这样的定性描述是没有标准的，因此信息的有效性不大。本书的后续章节
15、将说明解决方法。 忽略了非功能需求的局部性：我们经常会看到“所有查询响应时间都应该小于5秒”的描述，但是当查询稍长周期的数据量时这样的要求可能无法实现。因此开发人员会认为这项原则是可以破坏的。更科学的做法就是抓住具体的场景来描述。3. 设计约束设计约束看似简单，但如果不了解而导致收集需求时出现遗漏的现象。 非技术因素决定的选型对软件开发而言，技术选型会基于企业内部的相关规定。例如，必须采用J2EE技术；中间件必须采用WEBSPHERE等。 使用的软硬件条件与环境在决定架构、选择实现技术时会受到软硬件设备的影响，如果忽略了此种因素会造成不必要的麻烦。例如，当前导购人员使用的平台电脑的操作系统不支持FLASH插件、乡村支局点的电脑配置较低等。用户的环境也会对软件开发造成影响，需求人员应该搜集此类信息。2.2.
